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

Question

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

Не думаю, что они правильно помечены.

Answer 1

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

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

svn resolve --accept working -R .

, где . - конфликтующий каталог.

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

Пример:

Слияние / svn / Проект / филиалы / some-branch / Sources в / svn / Project / trunk ---> Дерево конфликтов

Слияние / SVN / Проект / филиалы / Some-Branch в / svn / Project / trunk ---> OK

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

Использование клиента версии 1.5 и клиента версии 1.6 в одном и том же хранилище может создать такую ​​проблему. (Я только что укусил себя.)

Answer 7

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

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

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

Answer 8

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

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Тогда сделай

svn cleanup

и

svn add *

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

svn ci .

Answer 9

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

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

Answer 10

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

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

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

Обсуждение: (см. Приложение)

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

Разрешение:

1. Вопреки тому, что советует волшебник, укажите диапазон, который охватывает ВСЕ пересмотры ... жизни филиала! следовательно, 394-HEAD ;
2. Теперь снова запустите тест на слияние и получите сигару. ().

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