2009-02-05 4 views
3

Интересно, как работают децентрализованные DVCS? Если нет центрального сервера, как машина разработчика может узнать и синхронизировать репозиторий с репозиториями других разработчиков. И как изменения объединяются? Поскольку отсутствие центрального сервера кажется мне, система может заставить каждый репозиторий иметь разные номера версий. И как обрабатываются разрешения конфликтов?Как работает децентрализованное поведение распределенных систем контроля версий?

ответ

2

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

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

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

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

  • Задай другой разработчик, чтобы тянуть изменения непосредственно из них
  • Нажмите непосредственно в копию другого разработчика
  • Нажимаем изменения в центре города, что другие могут вытащить из

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

Система может быть такой же централизованной или децентрализованной, как вы ее выбрали. Большинство проектов имеют некоторую централизацию по практическим соображениям, но в любой момент вилка может стать новым центральным хранилищем, или разработчики могут выбирать для торговли код между собой ad-hoc.

Когда коммиты взяты и объединены в вашу собственную копию, они применяются поверх любого общего предка, которого вы разделяете с восходящим репозиторием. Если есть конфликт, процесс слияния приостанавливается на этапе совершения конфликта, где произошел конфликт, и просит вас разрешить его, прежде чем продолжать применять оставшиеся коммиты поверх него. (Стандартные унифицированные маркеры различия используются для обозначения конфликтов.)

Большинство слияний происходит автоматически, но при конфликте часто бывает довольно тривиально. Самое приятное, что у вас нет шара конфликтов, охватывающих несколько коммитов: его гораздо легче разрешить, поскольку он приостанавливается в середине истории и позволяет вам справляться с ним в меньших логических кусках.

+0

Не определены ли связи с использованием хэшей SHA1? – Shoan

+0

Исправлено, спасибо. –

2

Презентация Скотта Чакона из RailsConf в прошлом году была потрясающей. Один из лучших запланированных и информационных переговоров, которые я когда-либо видел. Я отложить до него (в частности, на ваш вопрос, удаленная часть рабочего процесса начинается около 18 минут в него):

RailsConf Git Talk

Смежные вопросы