Я слышал, что многие из распределенных VCS (git, mercurial и т. Д.) Лучше подходят для слияния, чем традиционные, такие как Subversion. Что это значит? Что они делают, чтобы слияние было лучше? Можно ли это сделать в традиционной системе контроля версий?
Бонусный вопрос: уравнивает ли SVN 1.5 отслеживание слияния игровое поле вообще?
Похоже, что большинство ответов касается Subversion, так что здесь у вас есть один о Git (и других DVCS).
В распределенной системе контроля версий, когда вы объединяете одну ветвь с другой, вы создаете новую фиксацию слияния, которая запоминает, как вы разрешили слияние, и запоминает всех родителей слияния. Эта информация просто отсутствовала в Subversion до версии 1.5; для этого вам пришлось использовать дополнительные инструменты, такие как SVK или svnmerge. Эта информация очень важна при повторном слиянии.
Благодаря этой информации распределенные системы контроля версий (DVCS) могут автоматически находить общего предка (или общих предков), также известного как база слияния, для любых двух ветвей. Взгляните на схему исправлений ASCII-art ниже (я надеюсь, что она не была слишком сильно искажена),
---O---*---*----M---*---*---1
\ /
\---*---A/--*----2
Если мы хотим объединить ветку «2» в ветку «1», общим предком, который мы хотели бы использовать для генерации слияния, была бы версия (фиксация), помеченная «A». Однако, если система управления версиями не записывает информацию о родительских элементах слияния («M» - это предыдущее слияние тех же ветвей), она не сможет обнаружить, что это фиксация «A», и она найдет фиксацию «O». вместо этого в качестве общего предка (база слияния) ... который повторит уже включенные изменения и приведет к большому конфликту слияния.
Распределенная система управления версиями должна была делать это правильно, т.е. они должны были сделать слияние очень простым (без необходимости отмечать / отмечать родительские элементы слияния и предоставлять информацию о слиянии вручную) с самого начала, потому что это способ заставить кого-то другого получить код в проект заключалось не в том, чтобы дать ему / ей доступ к фиксации, а в том, чтобы извлечь из его / ее репозитория: получить коммиты из другого репозитория и выполнить слияние.
Вы можете найти информацию о слиянии в Subversion 1.5. в Выпуск Subversion 1.5 Примечания. Примечания: вам нужны разные (!) Параметры для объединения ветки в магистраль, чем для объединения магистрали в ветку, иначе. не все ветви равны (в распределенных системах контроля версий они [обычно] технически эквивалентны).
Возможности слияния SVN приличные, и простые сценарии слияния работают нормально - например, ветвь выпуска и ствол, где ствол отслеживает коммиты на RB.
Более сложные сценарии быстро усложняются. Например, давайте начнем со стабильной ветки (stable) и trunk.
Вы хотите продемонстрировать новую функцию и предпочитаете основывать ее на stable, поскольку она, в общем, более стабильна, чем trunk, но вы хотите, чтобы все ваши коммиты также были распространены на trunk, в то время как остальные разработчики все еще исправляют вещи в stable и разрабатывает вещи на trunk.
Итак, вы создаете ветвь demo, и граф слияния выглядит так:
stable -> demo -> trunk (ты)stable -> trunk (другие разработчики)Но что происходит, когда вы объединяете изменения из stable в demo, а затем объединяете demo в trunk, в то время как другие разработчики также объединяют stable в trunk? SVN путает слияния из stable, которые дважды объединяются в trunk.
Есть способы обойти это, но с git / Bazaar / Mercurial этого просто не происходит - они понимают, были ли уже объединены коммиты, потому что они идентифицируют каждую фиксацию по путям слияния, которые она принимает.
Отслеживание слияния в 1.5 лучше, чем отсутствие слияния, но это все еще ручной процесс. Мне действительно нравится, как он записывает, какие ревизии объединены, а какие нет, но это далеко не идеально.
Слияние имеет приятный диалог в 1.5. Вы можете выбрать, какие ревизии вы хотите объединить по отдельности или целую ветку. Затем вы запускаете слияние, которое происходит локально (и занимает НАВСЕГДА), когда затем вы получаете кучу файлов для чтения. Вам необходимо логически проверить каждый файл на правильное поведение (желательно с помощью модульных тестов файлов), и если у вас есть конфликты, вы должны их разрешить. Как только вы будете довольны, вы совершите фиксацию своего изменения, и в этот момент ветвь будет считаться объединенной.
Если вы сделаете это по частям, SVN запомнит то, что вы ранее сказали, что вы объединились, что позволит вам объединиться. Однако я нашел процесс и результат некоторых слияний странными, мягко говоря ...
Эти системы контроля версий могут работать лучше, потому что у них больше информации.
SVN pre-1.5, как и большинство VCS до последнего поколения, на самом деле не помнит, что вы где-то объединили два коммита. Он помнит, что у этих двух ветвей был общий предок, когда они впервые разветвились, но он не знает о каких-либо более поздних слияниях, которые можно было бы использовать в качестве общей основы.
Я ничего не знаю о сообщении SVN 1.5, так что, возможно, они улучшили это.
Беспокойный ответ: почему одни языки программирования лучше справляются с текстом / математикой, чем другие?
Реальный ответ: потому что они должны быть. распределенные VCS выполняют большую часть слияния там, где ни один из авторов конфликтующего кода не может настроить слияние вручную, потому что слияние выполняется третьей стороной. В результате инструмент слияния должен работать правильно большую часть времени.
По контракту с SVN вы делаете что-то необычное (и неправильное?), Если когда-либо в конечном итоге объединяете что-то, в чем вы не писали ту или иную сторону.
IIRC большинство VCS могут выполнять слияние с тем, что вы их просите использовать, поэтому (теоретически) нет ничего, что мешает SVN использовать механизмы слияния GIT / mercurial. YMMV
