Почему я получаю конфликты дерева в Subversion?

У меня была ветвь функции моего ствола и периодически сливала изменения из моего ствола в мою ветвь, и все работало нормально. Сегодня я пошел, чтобы объединить ветку обратно в ствол, и любые файлы, которые были добавлены в мой ствол после создания моей ветви, были помечены как "конфликт дерева". Есть ли способ избежать этого в будущем?

Я не думаю, что они должным образом помечены.

11 ответов


Я нашел решение, читая ссылку, которую дал Гэри (и я предлагаю следовать этому пути).

подведение итогов для разрешения конфликта дерева фиксация рабочего каталога С клиентом SVN 1.6.X вы можете использовать:

svn resolve --accept working -R .

здесь . - каталог, в конфликт.

предупреждение: "фиксация рабочего каталога" означает, что ваша структура песочницы будет той, которую вы фиксируете, поэтому, если, например, вы удалил какой-то файл из вашей песочницы, они также будут удалены из репозитория. Это относится только к конфликтующему каталогу.

таким образом, мы предлагаем SVN для разрешения конфликта (--resolve), принимая рабочую копию внутри вашей песочницы (--accept working), рекурсивно (-R), начиная с текущего каталога (.).

в TortoiseSVN, выбрав "разрешено" Правой Кнопкой Мыши, фактически решает эту проблему.


Subversion 1.6 добавлено дерево конфликтов для покрытия конфликтов на уровне каталога. Хорошим примером может быть локальное удаление файла, а затем обновление пытается изменить текст в этом файле. Другой - когда у вас есть subversion переименование файла, который вы редактируете, так как это действие добавления/удаления.

в блоге Subversion CollabNet есть отличная статья о Конфликты Дерево.


по моему опыту, SVN создает конфликт дерева всякий раз, когда я удаляю папку. Там, кажется, нет причин.

Я единственный, кто работает над моим кодом - > удалить каталог - > фиксация - > конфликт!

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

Я должен уточнить - я использую Subclipse. В этом-то и проблема! Опять же, я не могу дождаться, чтобы переключиться...


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

пример:

Merge /svn / Project / филиалы / некоторые-филиал/источники to / svn / Project / trunk - - - > конфликт дерева

Merge / svn / Project / филиалы / некоторые-филиал to / svn / Project / trunk - - - > OK

Это может быть глупая ошибка, но это не всегда очевидно, потому что вы думаете, что это что-то более сложное.


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

когда вы объединяете свою ветвь обратно в магистраль, SVN пытается сделать то же самое снова: он видит, что файл был создан в вашей ветви, и пытается создать его в вашей магистрали в фиксации слияния, но он уже существует! Это создает конфликт дерева.

способ избежать этого-сделать специальное слияние, a реинтеграции. Вы можете достичь этого с помощью --reintegrate переключатель.

вы можете прочитать об этом в документации: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

при слиянии вашей ветви обратно в магистраль, однако, основной математика совсем другая. Ветвь сейчас мешанина как дублированных изменений магистрали, так и частный филиал меняется, поэтому нет простого смежного диапазона изменений для копирования. От указав параметр --reintegrate, вы просите Subversion тщательно копируйте ТОЛЬКО те изменения, которые уникальны для вашей ветви. (И в факт, он делает это путем сравнивать самое последнее дерево хобота с самым последним дерево ветвей: результирующая разница-это именно ваши изменения ветвей!)

после реинтеграции ветви настоятельно рекомендуется удалить ее, иначе вы будете держать получение treeconflicts всякий раз, когда вы сливаетесь в другом направлении: от ствола до вашей ветви. (По той же самой причине,что и раньше.)

есть способ обойти это тоже, но я никогда не пробовал. Вы можете прочитать это в этом посте:Subversion филиал реинтеграции в v1.6


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

использование клиента версии 1.5 и клиента версии 1.6 для одного и того же репозитория может создать такую проблему. (Меня самого только что укусили.)


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

Что может случиться, так это то, что вы ранее уже объединили кучу изменений, которые вы включаете в свое текущее слияние. Например, в trunk кто-то отредактировал файл, а затем переименовал его. Если в первом слиянии вы включаете редактирование, а затем во втором слиянии включают оба отредактируйте и переименуйте (по существу, удалите), это также даст вам конфликт дерева. Причина этого в том, что ранее Объединенное редактирование появляется как ваше собственное, и поэтому удаление не будет выполнено автоматически.

Это может произойти в репозиториях 1.4 по крайней мере, я не уверен, помогает ли здесь mergetracking, введенный в 1.5.


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

Я решил проблему, переместив файл назад, зафиксировав и затем слияние моей ветке. Потом я вернул файл обратно. :) Это, казалось, сделало трюк.


у меня была похожая проблема. Единственное, что действительно сработало для меня, - это удалить конфликтующие подкаталоги с помощью:

svn delete --force ./SUB_DIR_NAME

затем скопируйте их снова из другого корневого каталога в рабочей копии, которая имеет их с:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

затем сделать

svn cleanup

и

svn add *

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

svn ci .

У меня была такая же проблема, и я решил ее, повторно выполнив слияние с помощью эти инструкции. В основном, он использует "слияние 2-URL" SVN для обновления trunk к текущему состоянию вашей ветви, не беспокоясь так много об истории и конфликтах деревьев. Спас меня от ручного исправления 114 конфликтов деревьев.

Я не уверен, что он сохраняет историю так, как хотелось бы, но в моем случае это того стоило.


сценарий, с которым я иногда сталкиваюсь:

Предположим, у вас есть ствол, из которого ты создал ветку. После некоторых изменений в trunk (в частности, создания каталога "some-dir") вы создаете ветку feature/fix, которую вы хотите позже объединить в ветку release (потому что изменения были достаточно небольшими, и функция/fix важна для выпуска).

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Если вы попытаетесь объединить ветвь функции/исправления непосредственно в ветвь выпуска, вы получите конфликт дерева (хотя каталог даже не существовал в ветви feature/fix):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

поэтому вам нужно явно объединить коммиты, которые были сделаны на транке перед созданием ветви feature/fix, которая создала каталог "some-dir" перед объединением ветви feature / fix.

Я часто забываю, что как то не нужно в git.