Функциональность слияния svn нарушена конфликтами деревьев

Я не знаю, когда команда svn решила вызвать у нас конфликты деревьев, но она полностью нарушила функцию слияния svn.

У меня есть ветка, и я хочу объединить последние изменения из основной ветки в ветку. Я уже сделал одно такое слияние, но это не удалось из-за конфликта деревьев. Вот команда:

$ svn --force merge -r 3185:3192 svn://chamar2/rx-services/SAMS .
svn: Attempt to add tree conflict that already exists

В первый раз, когда я попробовал это слияние (без --force), он только создал конфликт дерева и ничего не слил. Теперь он просто сообщает сообщение выше.

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

О чем они думали, когда это делали?

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

Есть ли способ сказать svn забыть о конфликтах деревьев и просто выполнить слияние, как раньше?

Я использую клиент 1.6 и более старый сервер svn (вероятно, 1.3.1).


merge svn tree-conflict
person Dean Schulze    schedule 27.07.2009    source источник
comment
SVN не добавлял конфликты деревьев как функцию; они являются неотъемлемой частью системы контроля версий. Теперь вы могли бы отметить, что SVN плохо справляется с работой и / или не передает сообщения о конфликтах деревьев, но, по крайней мере, он ДЕЙСТВИТЕЛЬНО обнаруживает их и пытается сообщить вам, что происходит.   -  person Tim Keating    schedule 12.08.2011

Ответы (4)


arrow_upward
15
arrow_downward

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

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

Спасибо за указатель на документацию Tortoise по конфликтам деревьев. Это единственная документация, которая касается работы с ветками, которую я видел. Однако приведенный пример не объясняет, почему у меня возникли конфликты деревьев в файлах, которые я изменил в ветке. К сообщениям о конфликтах деревьев нужно привыкнуть.

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

Марк Фиппард говорит, что более старая версия сервера не вызовет конфликтов деревьев. Сервер нужно обновлять только в том случае, если вы хотите поддерживать отслеживание слияний, а ваш сервер - до версии 1.5. Судя по всему, отслеживание слияния - единственное, чего не хватает на старых серверах svn:

http://eclipse.open.collab.net/ds/viewMessage.do?dsForumId=62&dsMessageId=332448
person Dean Schulze    schedule 29.07.2009
comment
конфликты деревьев: представьте каталог как текстовый файл с каждым подкаталогом как строкой. Теперь добавьте и удалите строки из этого файла и выполните слияние - вы получите конфликт. Это именно то, что происходит с конфликтами деревьев, просто редактор слияния не существует (очевидно, поскольку ответ состоит в том, чтобы скопировать каталоги в нужное место и пометить их как разрешенные). - person gbjbaanb; 11.09.2010

arrow_upward
11
arrow_downward

svn: Попытка добавить уже существующий конфликт деревьев

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

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

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

person Wim Coenen    schedule 28.07.2009
comment
У меня только что была попытка добавить конфликт деревьев, который уже существует, выполняя новое слияние. За ним следует Ошибка чтения буферного ответа на запрос REPORT - person PEELY; 16.04.2010
comment
-1: я получаю эту ошибку при новом слиянии без предыдущих слияний. Я считаю, что проблема связана с двумя конфликтами деревьев в одном слиянии. - person darreljnz; 02.08.2010

arrow_upward
2
arrow_downward

У меня есть дикая догадка, что вы наблюдаете плохое взаимодействие между клиентом 1.6 и сервером 1.3. Обнаружение конфликтов деревьев - это новая функция версии 1.6. Кроме того, поддержка слияния была изменена в 1.5 (и тогда она стала намного удобнее).

Я бы попробовал обновить сервер и формат репо до 1.6, еще одна вещь, которую нужно попробовать, - это использовать клиент 1.5 (без конфликтов деревьев) или 1.4 (и без нового слияния).

Опять же, это все предположение и может быть бесполезным ...

person Laurynas Biveinis    schedule 27.07.2009
comment
Я думал о понижении версии моего клиента до 1.5, но у svn есть неприятная привычка менять формат рабочей копии с каждой новой версией, и моя рабочая копия 1.6 не будет работать с клиентом 1.5. Возможно, мне придется понизить версию клиента и выполнить новую проверку. - person Dean Schulze; 28.07.2009

arrow_upward
0
arrow_downward

Привет, ребята, у меня была точно такая же проблема, конфликты деревьев, когда я пытался выполнить слияние svn. Оказывается, Лауринас был абсолютно прав. Это произошло из-за того, что репозиторий svn был старой версией. На сервере я зашел в каталог {repopath} \ db \ format и внутри файла формата он содержал "2".

Все, что я сделал, это сделал

svnadmin upgrade {repopath}

что было довольно безболезненно.

После этого, когда я попытался использовать отслеживание слияния, конфликты деревьев больше не возникали! Спасибо за совет!

person David    schedule 28.03.2012