Что делает некоторые системы управления версиями лучше при слиянии?
В соответствии с другими ответами, установите уровень ведения журнала вывода для подробного поиска и найдите там конфликты, которые расскажут вам, где искать дальше.
В моем случае он отправил меня в нескольких направлениях ищет источник ссылок, но в конце концов выяснилось, что проблема была одним из моих переносимых проектов библиотеки классов, она нацеливалась на неправильную версию и вытягивала свою собственную версию ссылок, а значит, и конфликты. Быстрая переадресация и проблема была решена.
5 ответов
Большинство ответов, кажется, о Подверсии, таким образом, здесь Вы имеете один о Мерзавце (и другой DVCS).
В распределенной системе управления версиями при слиянии одного ответвления в другого Вы создаете новый фиксация слияния , который помнит, как Вы разрешили, что слияние, и помнит всех родителей слияния . Этой информации просто недоставало Подверсии до версии 1.5; необходимо было использовать дополнительные инструменты, такие как SVK или svnmerge для этого. Эта информация очень важна при выполнении повторенного слияния.
Благодаря этим информационным распределенным системам управления версиями (DVCS) может автоматически , находят общего предка (или общих предков), также известными как основа слияния, для любых двух ответвлений. Смотрите на схему ASCII-творчества изменений ниже (я надеюсь, что она не сделала был слишком ужасно искажен),
---O---*---*----M---*---*---1
\ /
\---*---A/--*----2
, Если мы захотим объединить ответвление '2' в ответвление '1', то общий предок, которого мы хотели бы использовать для генерации слияния, будет версией (фиксация), отмеченная 'A'. Однако, если система управления версиями не записывала информацию о родителях слияния ('M' является предыдущим слиянием тех же ответвлений), это не смогло бы найти, что это - фиксация, и это нашло бы фиксацию 'O' как общий предок (основа слияния) вместо этого..., который уже повторит включенные изменения и приведет к большому конфликту слияния.
Распределенная система управления версиями должна была сделать его правильно, т.е. они должны были сделать слияние очень легким (не будучи должен отметить/отметить родителей слияния и предоставить информацию слияния вручную) с самого начала, потому что способ заставить кого-то еще получать код в проект не состоял в том, чтобы предоставить ему доступ фиксации, но вытягивать из его репозитория: получите фиксации из другого репозитория и выполните слияние.
можно найти информацию о слиянии в Подверсии 1.5. в Подверсия 1.5 Информации о версии . Знаменитые проблемы: Вам нужно отличающийся (!) опции объединить ответвление в соединительную линию, чем соединительная линия слияния в ответвление, иначе. не все ответвления равны (в распределенных системах управления версиями, они [обычно] технически эквивалентны).
Отслеживание слияния в 1,5 не лучше, чем никакое отслеживание слияния, но это - все еще в значительной степени ручной процесс. Мне действительно нравится способ, которым это записывает, какая версия и не объединяются, но не где почти прекрасный.
Слияние имеет хорошее диалоговое окно в 1,5. Можно выбрать, какие изменения Вы хотите объединить индивидуально, или целое ответвление. Вы тогда инициировали слияние, которое происходит локально (и берет НАВСЕГДА), когда тогда дает Вам набор файлов для прочтения. Необходимо проверить логически каждый файл на корректное поведение (предпочтительно пробегающий модульные тесты на файлах) и если у Вас есть конфликты, необходимо разрешить их. Однажды Ваше счастливое Вы делаете фиксацию своего изменения, и в той точке ответвление считают объединенным.
, Если Вы делаете это по частям, SVN будет помнить то, что Вы ранее сказали, что объединились, позволив Вам объединиться. Я нашел, что процесс и результат некоторых слияний были странными по меньшей мере однако...
Эти системы управления версиями могут добиться большего успеха, потому что у них есть больше информации.
SVN пред1.5, наряду с большей частью VCS перед последним поколением, на самом деле не помнит слияние двух фиксаций где угодно. Это помнит, что два ответвления совместно используют общего предка путь назад, когда они сначала отклонились, но это не знает о больше недавних слияниях, которые могли использоваться в качестве общего заземления.
я знаю, что ничто из SVN не отправляет 1.5, хотя, поэтому возможно, они изменили к лучшему это.
Легкомысленный ответ: Почему некоторые языки программирования лучше в тексте/математике, чем другие?
Реальный ответ: потому что они должны быть. распределенные VCSs делают большую часть там слияния в точке, где ни один из авторов конфликтующего кода не может настроить слияние вручную, потому что слияние делается третьим лицом. В результате инструмент слияния имеет для разбираний в нем большую часть времени.
В контракте с SVN Вы делаете что-то броское (и неправильно?), если Вы когда-нибудь заканчиваете тем, что объединили что-то, где Вы не записали одну сторону или другой.
IIRC большая часть VCSs может выйти из оболочки слияние к тому, что Вы просите, чтобы они использовали, таким образом, нет (теоретически) ничего препятствующего тому, чтобы SVN использовал механизмы слияния МЕРЗАВЦА / подвижные механизмы слияния. YMMV
Объединяющиеся возможности SVN достойны, и простые сценарии слияния хорошо работают - например, выпускают ответвление и соединительную линию, где соединительная линия отслеживает фиксации на RB.
более сложные сценарии являются сложными быстро. Например, позволяет, запускаются со стабильного ответвления (stable) и trunk.
Вы хотите продемонстрировать новую возможность и предпочесть основывать его на stable, поскольку это, ну, в общем, более стабильно, чем trunk, но Вы хотите, чтобы все Ваши фиксации были распространены к trunk также, в то время как остальная часть разработчиков все еще чинит вещи в stable и разрабатывает вещи на trunk.
, Таким образом, Вы создаете demo, ответвление и объединяющийся график похожи:
-
stable -> demo -> trunk(Вы) -
stable -> trunk(другие разработчики)
, Но что происходит, когда Вы объединяете изменения от [1 110] в [1 111], затем объединяетесь demo с [1 113], в то время как все время другие разработчики также объединяются stable в [1 115]? SVN запутывается со слияниями от [1 116] объединяемый дважды в [1 117].
существуют пути вокруг этого, но с мерзавцем/Базаром/Подвижным этого просто не происходит - они понимают, были ли фиксации уже объединены, потому что они идентификатор каждая фиксация через объединяющиеся пути это берет.