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

Question

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

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

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

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

Answer 1

Как упоминалось в более старой версии (2009 г.) Дизайн «Деревянный конфликт» документ:

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

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

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

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

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

Answer 2

Я нашел пост, предлагающий решение этой проблемы.Он собирается запустить:

svn resolve --accept working <YourPath>

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

Answer 3

Что, если поступающие изменения — именно те, которые вам нужны?Я не могу запустить svnsolve --accept их-полный

svn разрешить --принять базу

Answer 4

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

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

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