DVCS и потеря данных?

Почти после двух лет использования DVCS кажется, что один свойственный "дефект" является случайной потерей данных: Я потерял код, который не продвинут, и я знаю других людей, которые имеют также.

Я вижу несколько причин этого: удаленное дублирование данных (т.е., "фиксации должны перейти к удаленному хосту") не встроено, жизни репозитория в том же каталоге как код и понятие "взлома, 'пока у Вас нет чего-то для выпуска", распространено... Но это не относится к делу.

Мне любопытно знать: Вы испытали DVCS-связанную потерю данных? Или Вы использовали DVCS без проблемы? И, связанный, кроме "не забывают продвигать часто", есть ли что-нибудь, что может быть сделано для уменьшения риска?

5
задан B--rian 6 September 2019 в 15:04
поделиться

3 ответа

Я потерял больше данных из-за затирания незафиксированных изменений в централизованной VCS и последующего решения, что они мне действительно нужны, чем из всего, что я делал с DVCS. Частично это связано с тем, что я использую CVS почти десять лет и git меньше года, поэтому у меня было гораздо больше возможностей столкнуться с проблемами с централизованной моделью, но различия в свойствах рабочего процесса между две модели также являются основными факторами.

Интересно, что большинство причин для этого сводятся к «ПОТОМУ ЧТО легче отбросить данные, я, скорее всего, сохраню их, пока не буду уверен, что они мне не нужны» . (Единственная разница между отбрасыванием данных и их потерей состоит в том, что вы хотели их отбросить.) Самый большой способствующий фактор - это, вероятно, причуда моих привычек рабочего процесса - мой " поэтому повреждение или потеря в одном репо или даже катастрофическая потеря данных на компьютере, над которым я работал, с меньшей вероятностью уничтожат единственную копию данных. (Возможность сделать это является большим преимуществом распределенной модели над централизованной - когда каждая фиксация становится постоянной частью репозитория, психологический барьер для копирования предварительных изменений намного выше.)

Что касается минимизации риски, можно развить привычки, которые сводят их к минимуму, но вы должны развивать эти привычки. Здесь два общих принципа:

  • Данные не существуют, пока не будут поэтому повреждение или потеря в одном репо или даже катастрофическая потеря данных на компьютере, над которым я работал, с меньшей вероятностью уничтожат единственную копию данных. (Возможность сделать это является большим преимуществом распределенной модели над централизованной - когда каждая фиксация становится постоянной частью репозитория, психологический барьер для копирования предварительных изменений намного выше.)

    Что касается минимизации риски, можно развить привычки, которые сводят их к минимуму, но вы должны развивать эти привычки. Здесь два общих принципа:

    • Данные не существуют, пока не будут (Возможность сделать это является большим преимуществом распределенной модели над централизованной - когда каждая фиксация становится постоянной частью репозитория, психологический барьер для копирования предварительных изменений намного выше.)

      Что касается минимизации риски, можно развить привычки, которые сводят их к минимуму, но вы должны развивать эти привычки. Здесь два общих принципа:

      • Данные не существуют, пока не будут (Возможность сделать это - большая победа распределенной модели над централизованной - когда каждая фиксация становится постоянной частью репозитория, психологический барьер для копирования предварительных изменений намного выше.)

        Что касается минимизации риски, можно развить привычки, которые сводят их к минимуму, но вы должны развивать эти привычки. Здесь два общих принципа:

        • Данные не существуют, пока несколько копий в разных места. Есть привычки рабочего процесса что даст вам несколько копий бесплатно - например, если вы работаете в двух разных местах у вас будет причина подтолкнуть к общему месту в конце каждой рабочей сессии, даже если он не готов к публикации.
        • Не пытайся делать ничего умного, глупо или за пределами вашей зоны комфорта с единственной ссылкой на фиксацию вы можете захотеть оставить. Создать временный тег, к которому вы можете вернуться, или создайте временную ветку для выполнения операции на. (git reflog позволяет вы восстанавливаете старые ссылки после факт; Я не удивлюсь, если другие DVCS имеют аналогичную функциональность. Таким образом, ручная маркировка не может быть необходимо, но часто бывает больше в любом случае удобно.)
2
ответ дан 14 December 2019 в 19:21
поделиться

Я потерял данные из DVCS, как из-за удаления дерева вместе с репозиторием (не помня, что в нем была важная информация), так и из-за ошибок при использовании командной строки DVCS (git, в конкретном случае): некоторая операция, которая должна была отменить внесенное мной изменение, фактически удалила из репозитория несколько уже зафиксированных ревизий.

3
ответ дан 14 December 2019 в 19:21
поделиться

Существует внутреннее противоречие между распределением и проверкой того, что все «сохранено» (с исходным предположением, что сохранение означает резервное копирование где-то еще).

ИМО, это реальная проблема, только если вы работаете на нескольких компьютерах одновременно, выполняющих одну и ту же работу (или, точнее, в нескольких репозиториях: например, мне часто приходится делиться изменениями между несколькими виртуальными машинами на одном компьютере). В этом случае идеальным вариантом будет «централизованный» рабочий процесс: вы должны установить временный сервер, а в некоторых ветвях используйте централизованный рабочий процесс. Ни один из известных мне существующих DVCS (git / bzr / hg) не поддерживает это хорошо. Тем не менее, это было бы неплохо.

0
ответ дан 14 December 2019 в 19:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: