Способствуют ли распределенные системы контроля версий плохим привычкам резервного копирования?

Question

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

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

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

Это также означает, не так ли, что руководитель группы не может видеть все эти хорошие сообщения SVN о коммитах, чтобы иметь общее представление о том, что происходит в базе кода?

Является ли что-нибудь из этого реальной проблемой?

Answer 1

Я могу понять ваше беспокойство по поводу того, что разработчики забывают о резервных копиях после того, как их локальная разница исчезает (потому что они зафиксированы локально), и перестает мучить их обильным выводом. Я думаю, что решение может заключаться в лучших инструментах, инструментах moar! Вы можете настроить задание cron для каждого ящика разработчика, которое помещает каждый последний достижимый объект в их хранилище в центральное хранилище и помечает их в центральном хранилище (резервное копирование) ветвями с пространством имен. Я думаю, что "git push" может сделать это, учитывая правильный refspec. Тогда все, что вы не делаете, это влияет на состояние ваших публичных веток.

Но вам действительно нужен такой же агрессивный процесс резервного копирования, как и раньше, когда репо существовало только в одном месте? С DVCS вам нужна гораздо более высокая категория катастроф, чтобы потерять весь ваш код. Теперь вам нужен астероид или бомба, поражающая ваш офис (и всех членов вашей команды за пределами площадки), а не просто жесткий диск или RAID-контроллер, выходящий из строя. Обратите внимание, я не защищаю неряшливость; Я защищаю равный риск при меньших затратах.

Answer 2

Я не думаю, что у вас есть автоматизм в этом. Распределенная или централизованная VCS может быть объединена с резервным копированием (или нет). Это все вопрос дисциплины в команде.

То же самое для коммитов. Если в команде есть дисциплина для регулярного внесения изменений в нужные репозитории, у вас также может быть рабочий список рассылки коммитов.

В команде с централизованным VCS также могут развиваться вредные привычки. Вы всегда должны бороться с вредными привычками.

Answer 3

В большинстве мест я предполагаю, что, вероятно, все еще существует «центральный» репозиторий, из которого создаются и тестируются сборки. Если вы хотите, чтобы ваш код был в сборке, он должен передаваться централизованно.

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

Я бы также отметил, что если вы полагаетесь на коммиты, чтобы увидеть, что делают ваши сотрудники, у вас, вероятно, есть более серьезные проблемы, на которые вы могли бы обратить внимание ...

Answer 4

Наличие локальной копии хранилища может способствовать плохим привычкам резервного копирования, если таковые имеются. Однако ваш главный репозиторий ДОЛЖЕН быть зарезервирован.

«Локальная копия всего хранилища» имеет гораздо более важное применение, чем резервное копирование. Это уменьшает задержку изучения истории кодовой базы - скажем, различий между последней версией - от сетевой передачи в оба конца до поездки на локальный жесткий диск.

Это не так уж важно, если ваш главный репозиторий находится в вашей гигабитной локальной сети. Если вы работаете на удаленном компьютере, а хранилище находится на расстоянии более 600 мс по VPN, это имеет огромное значение.

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

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