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

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

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

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

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

svn resolve --accept working -R .

где .находится каталог в конфликте.

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

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

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

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

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

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

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

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

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

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

Пример:

Слияние / svn / Project / branch / some-branch / Исходники в / svn / Project / trunk ---> Конфликт дерева

Объединить / svn / Project / филиалы / some-branch to / svn / Project / trunk ---> OK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

все ревизии ... чего? Мало ли я знал, что клиент, должно быть, имел в виду « все ревизии цели ! О, МОЙ БОГ. Бедный дьявол, ты погиб здесь. Та ветка родилась @ 393, не могли бы вы прочитать свидетельство о рождении, ради бога?

Разрешение:

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

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

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

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

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

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Тогда делай

svn cleanup

а также

svn add *

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

svn ci .

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

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

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

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

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

Если вы затем попытаетесь объединить ветку feature / fix непосредственно с веткой release, вы получите конфликт дерева (даже если каталог даже не существовал в ветке 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.