Я Mercurial разработчик и работал консультантом Mercurial. Поэтому я нахожу ваши вопросы очень интересными и надеюсь ответить на них:
- В чем преимущество или ценность совершения локально? [...]
Вы правы в том, что в эти дни среды IDE могут отслеживать локальные изменения, помимо простых отмен / повторов. Однако между этими моментальными снимками файлов и полной системой контроля версий все еще существует разрыв в функциональности.
Местные коммиты дают вам возможность подготовить свою "историю" на местном уровне, прежде чем вы отправите ее на рассмотрение. Я часто работаю над некоторыми изменениями, включающими 2-5 коммитов. После того, как я сделаю коммит 4, я мог бы вернуться и немного изменить коммит 2 (возможно, я увидел ошибку в коммите 2 после того, как я сделал коммит 4). Таким образом, я буду работать не только над последним кодом, но и над последними двумя коммитами. Это тривиально возможно, когда все локально, но становится сложнее, если вам нужно синхронизироваться с центральным сервером.
- что если я сломаю жесткий диск? [...] так как это круто по сравнению с регистрацией в центральном репо?
совсем не круто! : -)
Однако даже при центральном репо вам все равно придется беспокоиться о незафиксированных данных в рабочей копии. Поэтому я бы сказал, что вы все равно должны иметь решение для резервного копирования.
По моему опыту, люди часто имеют большие объемы незафиксированных данных, лежащих в их рабочих копиях с централизованной системой. Клиенты рассказывали мне, как они пытались убедить разработчиков совершать как минимум раз в неделю .
Изменения часто остаются незафиксированными, потому что:
Они на самом деле не закончены. В коде могут быть отладочные операторы печати, могут быть неполные функции и т. Д.
Фиксация включается в trunk, и это опасно с централизованной системой, поскольку это влияет на всех остальных.
Для фиксации потребуется сначала объединить с центральным хранилищем. Это слияние может быть пугающим, если вы знаете, что в коде были и другие конфликтующие изменения. Слияние может быть просто раздражающим, потому что вы не все сделали с изменениями и предпочитаете работать из заведомо исправного состояния.
Фиксация может быть медленной, когда вам приходится разговаривать с перегруженным центральным сервером. Если вы находитесь в оффшорной зоне, коммиты еще медленнее.
Вы абсолютно правы , если считаете, что вышесказанное не является вопросом централизованного или распределенного контроля версий. С CVCS люди могут работать в разных ветках и, таким образом, тривиально избегать 2 и 3 выше. С отдельной ветвью выброса я также могу фиксировать столько, сколько я хочу, так как я могу создать другую ветку, где я фиксирую более полированные изменения (решение 1). Тем не менее, коммиты все еще могут быть медленными, поэтому можно применять 4.
Люди, которые используют DVCS, часто в любом случае отправляют свои «локальные» коммиты на удаленный сервер в качестве решения для резервного копирования бедного человека. Они не продвигаются к главному серверу, на котором работает остальная команда, а к другому (возможно, частному) серверу. Таким образом, они могут работать изолированно и при этом сохранять резервные копии вне сайта.
- Работа в автономном режиме или в самолете. [...]
Да, мне никогда не нравился этот аргумент. У меня хорошее интернет-соединение в 99% случаев, и я не летаю достаточно, чтобы это стало проблемой: -)
Однако реальный аргумент не в том, что вы не в сети, а в том, что вы можете сделать вид, что не в сети. Точнее, вы можете работать изолированно, не отправляя изменения сразу в центральное хранилище.
Инструменты DVCS разработаны на основе идеи о том, что люди могут работать в автономном режиме. Это имеет ряд важных последствий:
Слияние ветвей становится естественной вещью. Когда люди могут работать параллельно, разветвления естественным образом появляются в графе коммитов. Следовательно, эти инструменты должны быть действительно хорошими при объединении ветвей. Инструмент, такой как SVN, не очень хорош для объединения !
Git, Mercurial и другие инструменты DVCS объединяются лучше , потому что у них было больше испытаний в этой области, а не напрямую, потому что они распределены.
Больше гибкости. С DVCS вы можете свободно перемещать изменения между произвольными репозиториями. Я часто буду толкать / тянуть между моим домашним и рабочим компьютерами, не используя настоящий центральный сервер. Когда все готово для публикации, я помещаю их в такое место, как Bitbucket.
Многосайтовая синхронизация больше не является «корпоративной функцией», это встроенная функция. Поэтому, если у вас есть оффшорное местоположение, они могут настроить локальное хранилище-концентратор и использовать его между собой. Затем вы можете синхронизировать часы локальных узлов, ежедневно или когда вам это удобно. Для этого не требуется ничего, кроме cronjob, который запускает hg pull или git fetch через равные промежутки времени.
Лучшая масштабируемость, поскольку больше логики на стороне клиента. Это означает меньшее обслуживание центрального сервера и более мощные инструменты на стороне клиента.
Ожидается, что с DVCS я смогу выполнять поиск по ключевым словам по ревизиям кода (а не только по сообщениям о фиксации). При централизованном инструменте обычно требуется настроить дополнительный инструмент индексирования.