Вопрос слияния SVN

Question

У меня есть каталог под контролем subversion. Я создал из него ветку просто для проверки слияния. Я взял файл, изменил строку X в стволе как «abc» и изменил ту же строку X, что и «def» в своей ветви.

Затем из рабочей ветки я сделал:

svn merge branchURL trunkURL .

Он обновил файл с содержанием «abc» в этом номере строки, то есть он не дал мне конфликт с тем же номером строки, что svn update дал бы мне, если бы я сделал это в том же рабочем каталоге и кто-то совершил «def» в хранилище.

Так svn merge просто заменяет контент при объединении и не вызывает никаких конфликтов?

И если это так, то сама причина разветвления proj dir из основного ствола была бы бесполезна, если нельзя объединить таким образом, чтобы сохранить изменения как в стволе, так и в ветвлении.

Answer 1

Вы понимаете, что

svn merge branchUrl trunkUrl branchWorkingCopy

На самом деле, да?

Вот перевод:

Определите набор изменений, необходимых для того, чтобы сделать содержимое branchUrl идентичным содержимому trunkUrl . Теперь выполните эти изменения в branchWorkingCopy .

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

Если вы просто хотите скопировать выбранные изменения из trunk в branch , вам нужно указать Subversion , какие изменения вы хотите скопировать и использовать другая форма команды слияния:

svn merge -r100:103 trunkUrl branchWorkingCopy

Что означает: определить набор изменений, необходимых для получения значения от r100 до r103 на соединительной линии. Выполните эти изменения в рабочей копии (филиала). Обратите внимание, что этот «набор изменений» не будет включать в себя изменения, сделанные r100, поскольку они фиксируются набором изменений, необходимых для перехода от r99 к r100. Диапазон версий в Subversion: полуоткрытый .

Кроме того, подумайте о прочтении подробного руководства , если вы еще этого не сделали.

Answer 2

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

Итак, если вы разветвились (или слились в последний раз) в ревизии 100, транк в настоящее время равен 200, и вы хотите объединить изменения из ствола в вашу ветку, то в рабочем каталоге ветки вы делаете:

svn merge -r 100:200 trunkURL

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

svn merge без -r определяет две указанные вами локации и применяет эту разницу к рабочему каталогу. Поэтому я предполагаю, что произошло то, что конфликта нет, потому что ваш рабочий каталог совпадает с главой филиала. Таким образом, разница между заголовком ветви и заголовком магистрали может быть применена к вашему рабочему каталогу без каких-либо проблем. Это не то, что вы хотите сделать: все, что вам нужно, это изменить ваш рабочий каталог, чтобы он соответствовал транку. Попробуйте внести еще одно изменение в ветку, зарегистрируйтесь и повторите процесс. Если слияние отменяет это изменение (потому что оно не в транке), то я прав насчет этой формы svn слияния, но, как я уже сказал, я не использовал ее.

[Редактировать: до версии 1.5 svn ...]

Рабочие каталоги и ветки - это не одно и то же в SVN, и, как это ни раздражает, нужно учитывать различия. SVN требуется больше информации для того, чтобы выполнить слияние веток, которое вы хотите, чем для обновления или регистрации, потому что на самом деле он не учитывает автоматически, где произошла ветвь, как он всегда учитывает, где был извлечен рабочий каталог. Я уверен, что для этого есть причина, я просто не знаю точно, что это такое: возможно, потому что svn copy - это больше, чем просто ветки.

[Редактировать ... но, согласно комментарию Джошуа МакКиннона к этому ответу, начиная с 1.5 svn поддерживает правильные слияния ветвей, которые выполняют то, что вы хотите автоматически. Укажите URL, с которого вы объединяете, и запустите команду в рабочем каталоге того, с чем вы объединяетесь. Так что в этом случае попробуйте

svn merge trunkURL

и вы должны увидеть конфликт. Возможно, вам придется сначала восстановить рабочий каталог.]

Answer 3

поэтому svn merge просто заменяет содержание при объединении, а не принести какие-либо конфликты?

Ну нет. Я не могу точно указать, что вы сделали неправильно, но флаги слияния конфликтуют так же, как обновление.