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

Question

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

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

Answer 1

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

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

svn resolve --accept working -R .

где . это каталог в конфликте.

ПРЕДУПРЕЖДЕНИЕ: «Фиксация вашего рабочего каталога» означает, что ваша структура песочницы будет той же, которую вы фиксируете, поэтому, если, например, вы удалили какой-то файл из своей песочницы, они также будут удалены из репозитория.Это применимо только к конфликтующему каталогу.

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

В TortoiseSVN выбор «Решено» при щелчке правой кнопкой мыши фактически решает эту проблему.

Answer 2

В Subversion 1.6 добавлены конфликты деревьев для устранения конфликтов на уровне каталогов.Хорошим примером может служить ситуация, когда вы локально удаляете файл, а затем обновление пытается внести изменения в текст этого файла.Другой вариант — когда у вас есть подрывная версия. Переименуйте файл, который вы редактируете, поскольку это действие «Добавить/Удалить».

В блоге CollabNet Subversion есть отличная статья на эту тему. Конфликты деревьев.

Answer 3

По моему опыту, SVN создает конфликт дерева ВСЕГДА, КОГДА я удаляю папку.Кажется, нет никакой причины.

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

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

Я должен уточнить - я использую Подклип.Наверное, в этом проблема!И снова мне не терпится переключиться...

Answer 4

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

Пример:

Merge/Svn/Project/Branches/Come-ranch/источники в/svn/project/trunk ---> конфликт деревьев

Merge/Svn/Project/Branches/Come-ranch to/svn/project/trunk ---> ok

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

Я решил проблему, переместив файл обратно, зафиксировав и затем объединение моей ветки.Затем я переместил файл обратно.:) Кажется, это помогло.

Answer 9

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

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Тогда делай

svn cleanup

и

svn add *

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

svn ci .

Answer 10

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

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

Answer 11

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

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

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

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

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

Поэтому вам необходимо явно объединить коммиты, которые были сделаны в магистрали, перед созданием ветки функций/исправлений, которая создала каталог «some-dir», прежде чем объединять ветку функций/исправлений.

Я часто забываю об этом, поскольку в git это не обязательно.

Answer 12

До сегодняшнего дня, по крайней мере 3 месяца назад, я регулярно сталкивался с сотнями конфликтов деревьев при попытке объединить ветку обратно в ствол (используя ЧерепахаSVN 1.11).Независимо от того, перебазировано или нет, кстати.Я использую TortoiseSVN начиная с его версии v1, еще в 2004 году, и постоянно реинтегрировал ветки.Полагаю, что-то недавно произошло?

Итак, сегодня я провел этот простой эксперимент и обнаружил, что создает эти сумасшедшие конфликты:

1. Я отделил багажник @393;
2. Я случайным образом изменил десятки файлов, а также создал новые;
3. Я совершил.Теперь @395 (коллега раскошелился на 394, чтобы исполнить свои собственные вещи).
4. Затем я попытался реинтегрировать ветку обратно в магистраль, только для проверки;следуя рекомендациям TortoiseSVN в мастере:«чтобы объединить все версии (реинтегрировать), оставьте это поле пустым».Для этого я щелкнул правой кнопкой мыши папку ствола и выбрал «TortoiseSVN > Объединить из /path/to/branch», и я оставил диапазон оборотов пустым, как указано в диалоге.

Обсуждение: (См вложение)

все редакции...которого? Мало ли я знаю что клиент, должно быть, имел в виду "все ревизии таргета! (trunk)", так как в процессе реинтеграции этой ветки я увидел упоминание "Слияние ревизий 1-HEAD"!МОЙ БОГ.Бедный Дьявол, ты здесь падаешь насмерть.Эта ветка родилась @393, вы не можете прочитать ее свидетельство о рождении, ради бога?

Разрешение:

1. Вопреки советам мастера, указывайте диапазон, охватывающий ВСЕ ревизии... жизни ветки!поэтому, 394-ГОЛОВКА;
2. теперь снова запустите этот тест слияния и получите сигару.().

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