SVN как разрешить новые конфликты дерева при добавлении файла на две ветви

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

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

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

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

94
merge svn tree-conflict

4 ответов

Как упоминалось в более старой версии (2009)"дерево конфликта" дизайн документ:

конфликт XFAIL от слияния add over versioned file

этот тест делает слияние, что приносит добавление файла без истории на существующий версионный файл.
Это должен быть конфликт дерева в файле ''. Фиксированные ожидания в r35341.

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

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

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

39

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

svn resolve --accept working <YourPath>

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

159

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

svn resolve --accept base

9

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

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

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

1