Я слышал, что многие из распределенных VCS (git, mercurial и т.д.) лучше объединяются, чем традиционные, такие как Subversion. Что это значит? Что они делают, чтобы сделать сливание лучше? Могут ли быть эти вещи в традиционной VCS?
Бонусный вопрос: совместим ли SVN 1.5 с отслеживанием слияния игрового поля?
Большинство ответов, по-видимому, касаются Subversion, поэтому здесь у вас есть о Git (и других DVCS).
В распределенной системе управления версиями, когда вы объединяете одну ветку в другую, вы создаете новую фиксацию слияния, которая запоминает, как вы решили слияние, а запоминает всех родителей слияния. Эта информация просто отсутствовала в Subversion до версии 1.5; для этого вам пришлось использовать дополнительные инструменты, такие как SVK или svnmerge. Эта информация очень важна при повторном слиянии.
Благодаря этой информации распределенные системы управления версиями (DVCS) могут автоматически находить общего предка (или общих предков), также известного как база слияния, для любых двух ветвей. Взгляните на диаграмму ASCII-art изменений ниже (я надеюсь, что это не слишком ужасно исказилось),
---O---*---*----M---*---*---1
\ /
\---*---A/--*----2
Если мы хотим объединить ветвь '2' в ветвь '1', общим предком, который мы хотели бы использовать для генерации слияния, была бы версия (commit) с пометкой "A". Однако, если система контроля версий не записывала информацию о слиянии родителей ( "M" - это предыдущее объединение тех же ветвей), он не сможет найти, что это commit "A", и он найдет commit "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 лучше, чем отсутствие слияния, но это все еще очень ручной процесс. Мне нравится, как он записывает, какой rev есть и не сливается, но его нет, где почти идеально.
Слияние имеет приятный диалог в 1.5. Вы можете выбрать, какие изменения вы хотите объединить индивидуально, или всю ветвь. Затем вы вызываете слияние, которое происходит локально (и принимает FOREVER), когда оно дает вам кучу файлов для чтения. Вы должны логически проверять каждый файл на предмет правильного поведения (желательно, проверяя отдельные тесты в файлах), и если у вас есть конфликты, вы должны их разрешить. Как только ваш счастливый вы совершите фиксацию вашего изменения, и в этот момент ветвь считается объединенной.
Если вы сделаете это по частям, SVN запомнит то, что вы ранее сказали, что вы слились, что позволяет вам слиться. Я обнаружил, что процесс и результат некоторых слияний кажутся странными, если не сказать...
Эти системы управления версиями могут улучшиться, потому что у них больше информации.
SVN pre-1.5, наряду с большинством VCS до последнего поколения, на самом деле не помнит, что вы объединили две коммиты в любом месте. Он помнит, что у двух ветвей есть общий предок, когда они сначала разветвляются, но он не знает о каких-либо более поздних слияниях, которые можно было бы использовать в качестве общей основы.
Я ничего не знаю о SVN post 1.5, поэтому, возможно, они улучшили это.
Ответ на вопрос: почему некоторые языки программирования лучше подходят для текста/математики, чем другие?
Настоящий ответ: потому что они должны быть. распределенные VCS многое делают слиянием в точке, где ни один из авторов конфликтующего кода не может сгладить слияние вручную, потому что слияние выполняется третьей стороной. В результате инструмент слияния должен получить правильное время от времени.
В контракте с SVN вы делаете что-то напуганное (и не так?), если вы когда-нибудь закончите слияние чего-то, где вы не писали ни одну сторону, ни другую.
IIRC Большинство VCS могут выложить слияние на все, что вы попросите их использовать, поэтому (теоретически) ничего не мешает SVN использовать двигатели слияния GIT/mercurial. YMMV