Как работают DVCS (DRCS)?

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

Может ли кто-нибудь указать мне на какой-нибудь текст, объясняющий, как именно работают улучшения? Откуда базар знает, что я переименовал файл? Что, если я переименую два файла как часть одного и того же коммита? Что происходит, когда я выполняю рефакторинг, помещая половину содержимого файла в новый файл, изменяя все отступы и удаляя пробелы почти в каждой строке?

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


Связанный вопрос с полезным ответом:

Почему ветвление и слияние проще в Mercurial, чем в Подрывная деятельность?


person Community    schedule 05.09.2008    source источник


Ответы (5)


Слияние по своей сути не лучше в DVCS, просто их было бы практически очень сложно использовать, если бы ветвление/слияние не работало правильно (возможно, svn неправильно реализует ветвление/слияние), потому что вместо того, чтобы сделать проверку, вы создание новой ветки каждый раз, когда вы начинаете работать над проектом из существующего кода. Я думаю, что некоторые проприетарные централизованные SCS правильно обрабатывают слияние/ветвление.

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

http://revctrl.org/CategoryMergeAlgorithm

По крайней мере, hg, bzr и git могут использовать внешние утилиты слияния.

person David Cournapeau    schedule 16.09.2008

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

Переименование обрабатывается по-разному в разных DVCS. Git, например, вообще не отслеживает переименование, потому что Линусу это было неважно. Mercurial записывает их как «скопировать старый файл в новый, удалить старый». По словам Марка Шаттлворта, основателя Canonical, Darcs и Bazaar — единственные DVCS, поддерживающие переименование файлов. правильно.

Откуда базар знает, что я переименовал файл?

Переименования задаются пользователем точно так же, как добавление или удаление файлов. Используйте команду «bzr rename <old> <new>», чтобы пометить файлы или каталоги для переименования. Если вы уже переименовали файл в дереве, вы можете использовать опцию «--after».

Что, если я переименую два файла как часть одного и того же коммита?

Затем вы вводите «bzr rename <old> <new>» один раз для каждого файла. Bazaar не пытается угадать, какие файлы были переименованы.

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

Затем вы вводите «bzr add» в новом файле, так как на самом деле вы его не переименовываете.

person John Millikin    schedule 05.09.2008

Ниже приводится обсуждение того, как darcs (http://darcs.net) работает с исправлениями — http://darcs.net/manual/node9.html.

person benefactual    schedule 16.09.2008

Крутая статья для прочтения

http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

person Setori    schedule 22.10.2008

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

person Kyle Cronin    schedule 05.09.2008