Почему ветвление и слияние легче в Mercurial, чем в Subversion?

Question

Обработка множественных слияний в ветвях в Subversion или CVS - это только одна из тех вещей, которые нужно испытать. В Mercurial (и, вероятно, в любой другой распределенной системе) очень легко отслеживать ветки и слияния, но я не знаю почему. Кто-нибудь еще знает?

Мой вопрос проистекает из того факта, что с Mercurial вы можете применить рабочую практику, аналогичную той, которая используется в центральном репозитории Subversions / CVS, и все будет работать нормально. Вы можете выполнить несколько слияний в одной ветви, и вам не понадобятся бесконечные клочки бумаги с номерами коммитов и именами тегов.

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

Должно быть принципиальное различие в том, как все это работает.

Answer 1

В Subversion (и CVS) хранилище - это прежде всего. В мерзавце и ртутный, на самом деле нет концепции хранилища в так же; здесь изменения являются центральной темой.

+ 1

Проблемы в CVS / SVN происходят из-за того, что эти системы не помните родительские изменения. В Git и Mercurial, коммит может иметь не только несколько дочерних элементов, но и несколько родители!

Это легко заметить с помощью одного из графических инструментов, gitk или hg view. В следующем примере ветка # 2 была разветвлена ​​от # 1 в коммит A, и с тех пор был объединен один раз (в M, объединен с коммитом B):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

Обратите внимание, что у А и В двое детей, тогда как у М есть два родителей . Эти отношения записаны в хранилище. Скажем, хранитель Ветка №2 теперь хочет объединить последние изменения из ветки № 1, они могут введите команду, такую ​​как:

$ git merge branch-1

и инструмент автоматически узнает, что base - это B, потому что был записан в коммите М, предке кончика № 2 - и что он должен объединить все, что случилось между B и C. CVS не записывает эту информацию, как и SVN до версия 1.5. В этих системах граф будет выглядеть так:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

где М - просто гигантский «раздавленный» коммит всего, что произошло между А и В, применяется поверх M. Обратите внимание, что после того, как дело сделано, нет никаких следов оставил (кроме потенциально в удобочитаемых комментариях) того, где M сделал от , сколько коммитов было свернуто вместе - создание история гораздо более непроницаемая.

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

(связанная) проблема в том, что нет возможности ответить на вопрос: содержат B? ", где B представляет собой потенциально важное исправление ошибки. Итак, почему бы просто не записать эту информацию в коммит, так как известно во время слияния!

P.-S. - У меня нет опыта с возможностями записи слиянием SVN 1.5+, но рабочий процесс кажется гораздо более надуманный, чем в распределенных системах. Если это действительно так, то, вероятно, потому что - как уже упоминалось в приведенном выше комментарии - основное внимание уделяется организации хранилища, а не самим изменениям.

Answer 2

Потому что Subversion (по крайней мере, версия 1.4 и ниже) не отслеживает то, что было объединено. Для Subversion слияние в основном такое же, как и для любого коммита, в то время как на другом контроле версий, таком как Git, запоминается то, что слилось.

Answer 3

Не тронутый ни одним из уже предоставленных ответов, Hg предлагает превосходные возможности слияния, поскольку при объединении изменений использует больше информации ( hginit.com ):

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

Конечно, запоминание того, что было объединено в последний раз (пункт, который рассматривается в большинстве ответов, представленных здесь), также является огромной победой.

Оба улучшения, однако, сомнительны, так как Subversion 1.5+ хранит дополнительную информацию о слиянии в форме свойств Subversion: у этой информации нет очевидной причины, почему слияние в Subversion не могло реализовать слияние так же успешно, как Hg или Git. Я не знаю, так ли это, но похоже, что разработчики Subversion уже пытаются обойти эту проблему.

Answer 4

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

Answer 5

В Subversion (и CVS) хранилище - это прежде всего. В git и mercurial концепция репозитория не совсем одинакова; здесь изменения являются центральной темой.

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

Answer 6

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

Если Mercurial может упростить настройку слияния, я могу сказать, что это сделает слияние на 100% легче, чем Subversion.