SVN, как разрешить конфликты нового дерева, когда файл добавляется в две ветви

95

При объединении пары веток (с использованием SVN 1.6.1), когда файл был добавлен в обе ветки (а затем работал в этих отдельных ветвях), я получаю один из конфликтов нового дерева:

      C foo.txt
  >   local obstruction, incoming add upon merge

Мне нужны изменения из обеих веток, но конфликт деревьев не дает мне обычных файлов .working, .merge-left и .merge-right, что понятно из-за характера конфликта. Таких конфликтов довольно много, и таких, где в каждой ветке произошло удаление одного и того же файла, но их легко разрешить.

Как я могу решить эту проблему? Редбин книга SVN (для 1.6) не освещает эту ситуацию.

svn  merge  tree-conflict 
— Дефузия
источник

Ответы:

40

Как упоминалось в более ранней версии (2009 г.) проектного документа «Tree Conflict» :

Конфликт XFAIL из-за слияния добавленного файла с версией

Этот тест выполняет слияние, которое добавляет файл без истории к существующему версированному файлу .
Это должен быть конфликт деревьев в файле local obstruction, incoming add upon mergeразновидности ' '. Исправлены ожидания в r35341.

(Это, кстати, также называется «злыми близнецами» в ClearCase):
файл создается дважды (здесь «добавляется» дважды) в двух разных ветвях, создавая две разные истории для двух разных элементов, но с тем же именем.

Теоретическое решение состоит в том, чтобы вручную объединить эти файлы (с помощью внешнего инструмента сравнения) в целевой ветке ' B2'.

Если вы по- прежнему работаете на исходной ветви, идеальный сценарий был бы удалить этот файл из исходной ветви B1, слейте обратно от B2до B1того , чтобы сделать этот файл видимым на B1(вы будете потом работать на тот же элемент).
Если обратное слияние невозможно, потому что слияние происходит только с B1по B2, то для каждого слияния потребуется ручное слияние B1->B2.

— VonC
источник
2
Ссылка на документ о дизайне "конфликта деревьев"
— испорчена
4
Забавно то, что даже если оба добавленных файла идентичны, они все равно отображаются как конфликтующие. Это действительно не следует отмечать как конфликт.
— SantiBailors
1
@SantiBailors Так смешно, что я умираю прямо сейчас. Умираю за моего старого друга мерзавца ...
— Winter
163

Я нашел сообщение, предлагающее решение для этого . Вот-вот запустится:

svn resolve --accept working <YourPath>

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

— Лукмдо
источник
2
Спасибо, это тоже решает: C foo.txt> local add, добавление при обновлении
— lazysoundsystem
5
спасибо, у меня тоже сработало, но я должен был сделать это: svn resolve --accept working FILENAME
— ajacian81
5
да, вам нужно имя файла. Он принимает '.' (текущий каталог). Мне также нужно было сделать это рекурсивно, поэтому: "svn resolve --accept working --recursive." решает все в пользу вашей рабочей копии (опасно! Вы можете сдуть чужие изменения, когда делаете это, как всегда при разрешении конфликтов)
— Гарри Вуд
Я использую псевдоним, который я создал, чтобы перечислить все файлы, конфликтующие между деревьями: alias mtc='stat | awk "BEGIN { FS=\" \" } /^.{6}C/ { print \$NF }"' Затем я могу использовать его в качестве аргумента команды разрешения, например: svn resolve --accept working $(mtc)
— Эрл Дженкинс,
1
На самом деле вам нужно также указать ресурс, например: svn resolve --accept working path/index.html
— Tomasz Kuter
9

Что, если входящие изменения - это те, которые вам нужны? Я не могу запустить svn resolve --accept theirs-full

svn resolve --accept base

— Габриэль Ф. Т. Гомеш
источник
4
Думаю, я неправильно понял вопрос. 'base' действительно эквивалентно 'theirs-full' при использовании 'svn resolve', но это не решает вашу проблему. Вместо этого я разделил его на две части: 1) удалить локальный конфликтующий каталог (или файл), 2) объединить. Это должно работать без конфликтов, и, поскольку «входящие изменения - это те, которые вы хотите», мне было бы наплевать на удаленные элементы,
— Габриэль FT Gomes
3

Мне просто удалось довольно тщательно заклинивать себя, пытаясь последовать совету user619330 выше. Ситуация была такой: (1): я добавил несколько файлов во время работы над моей начальной веткой, branch1; (2) Я создал новую ветку, ветку2 для дальнейшей разработки, отделив ее от основной ветви, а затем объединив мои изменения из ветки 1 (3) Сотрудник скопировал мои моды из ветки 1 в свою собственную ветку, добавил дополнительные моды, а потом слился обратно в багажник; (4) Теперь я хотел объединить последние изменения из основной ветки в мою текущую рабочую ветку, ветку2. Это с svn 1.6.17.

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

Ну нет. Обновление другой копии branch2 привело к старой версии файлов (предварительное слияние). Итак, теперь у меня есть две разные рабочие копии branch2, предположительно обновленные до одной и той же версии, с двумя разными версиями файлов, и обе настаивают на том, что они полностью обновлены! Проверка чистой копии branch2 привела к получению старой (pre-trunk) версии файлов. Я вручную обновляю их до версии ствола и фиксирую изменения, возвращаюсь к своей первой рабочей копии (из которой я первоначально отправил изменения ствола), пытаюсь обновить ее и теперь получаю ошибку контрольной суммы для рассматриваемых файлов. Удалите каталог, о котором идет речь, получите новую версию с помощью обновления, и, наконец, у меня должна быть хорошая версия branch2 с изменениями магистрали. Я надеюсь. Будьте осторожны, разработчик.

— Dewtell
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.