То, что в настоящее время (2011 г.) является рекомендованным хранилищем исходного кода для компании с одним местоположением.
Git или Mercurial.
Распределенные репозитории трудны, потому что есть 2 шага для проверки и регистрации.
Звучит для менякак вы видите DVCS как «Subversion, но распределенный».Они не такие и думают о них так, что вы упустите их преимущества.
Для DVCS нет двух шагов для фиксации.Есть два шага для фиксации с помощью Git (stage, затем commmit), но это функция Git, а не функция DVCS.
Я думаю (пожалуйста, исправьте меня, если я ошибаюсь), что вы считаете эти два шагабыть commit (локальный) и push (в центральное хранилище).Это необходимо сделать только в том случае, если вы хотите, чтобы каждое внесенное каждым разработчиком изменение было немедленно доступно другим.
В централизованных системах (например, SVN) это просто неизбежно.С DVCS вы можете использовать коммиты в качестве резервных точек вместо публикаций.
Разница в том, что в SVN вы не можете позволить себе коммитить неполный код, потому что он влияет на всю команду (вы делаете, и пока вы не исправитеэто никто из команды не будет иметь полезный код).В DVCS вы фиксируете (и объединяете) как хотите (локально) и синхронизируете только тогда, когда у вас есть что-то стабильноеКак только вы к этому привыкнете, «путь SVN» выглядит излишне узким.
То, как мы работали с DVCS, было следующим: у нас (8 разработчиков или около того) был один центральный репозиторий, который синхронизировался еженедельно,перед каждым внутренним выпуском (для команды тестирования).Каждый из нас будет синхронизировать свои источники перед сборкой (извлекать изменения с сервера, объединять, извлекать).Затем один из нас сделает сборку на серверном компьютере.
Много раз у нас было два коллеги, которые работали над двумя сторонами новой функции и синхронизировали бета-код только между собой.Когда у нас было что-то стабильное, мы помещали это на сервер.В то же время другим разработчикам не приходилось видеть неполный или неработающий код, а центральная кодовая база оставалась стабильной, в то время как мы могли по-прежнему фиксировать и иметь все преимущества контроля версий.полная копия хранилища в каждой системе.
Это хорошо.Это означает, что благодаря созданию локального репозитория вы получаете 100% полное резервирование, и единственная точка отказа сервера эффективно устраняется.В случае сбоя жесткого диска вашего сервера вы просто клонируете локальный репозиторий от одного из разработчиков на новый жесткий диск сервера.
Это приблизительно.50 ГБ с нашей текущей системой.
Но вы синхронизируете их только один раз для каждого клиента.После начальной синхронизации все последующие являются инкрементными.
Это занимает много времени, если вы хотите проверить новую систему.
Вы можете быть удивлены.И Hg, и Git сжимают данные перед передачей (я не уверен, что SVN делает это), и они также сжимают сам репозиторий.Учитывая, что эти системы хранят изменения вместо файлов (т. Е. Дельты изменений, а не полные файлы), хранилище может быть меньше при использовании DVCS, чем при использовании SVN.
Недостаток (вы можете прочитать этот «верх», если выучитывайте проблемы с избыточностью и резервным копированием), так как вы копируете полный репозиторий локально с каждым процессом клонирования.
Нет резервной копии локальных систем.
Нет необходимости- резервное копирование репозиториев DVCS обычно не является проблемой.Каждая локальная система представляет собой полную копию центрального репозитория (содержащую полную историю), а центральный репозиторий - полную резервную копию каждого клиентского репозитория (синхронизируется при каждом извлечении / извлечении).
С одним центральным репозиторием и одним разработчикому вас 100 + 100% резервирование.С двумя разработчиками, 100 + 200% избыточности.
Не безопаснее, чем это.
В настоящее время мы используем Subversion. Но у Subversion есть большие проблемы со слиянием.
Что касается слияния, subversion по своей сути не работает, поскольку SVN не хранит метаданные, чтобы решить, как объединить (поскольку SVN отслеживает файлы, а не изменения). Когда SVN объединяется, он пытается сделать обоснованные предположения, что в тривиальных случаях нормально. В нетривиальных случаях вы пытаетесь решить сложную (для человека) проблему вручную, когда это должен делать ваш инструмент / компьютер.