Svn tree conflict что делать
SVN как разрешить новые конфликты дерева при добавлении файла на две ветви
при объединении нескольких ветвей (с использованием SVN 1.6.1), где файл был добавлен на обе ветви (а затем работал в этих отдельных ветвях), я получаю один из новых конфликтов дерева:
Как я могу решить эту проблему? Книга SVN redbean (для 1.6) не охватывает эту ситуацию.
4 ответов
Как упоминалось в более старой версии (2009)»дерево конфликта» дизайн документ:
конфликт XFAIL от слияния add over versioned file
этот тест делает слияние, что приносит добавление файла без истории на существующий версионный файл.
Это должен быть конфликт дерева в файле ». Фиксированные ожидания в r35341.
(это также называется «злые Близнецы» в ClearCase кстати):
файл создается дважды (здесь «добавлен» дважды) в двух разных ветвях, создавая две разные истории для двух разных элементов, но с тем же именем.
теоретическое решение состоит в том, чтобы вручную объединить эти файлы (с помощью внешнего инструмента diff) в целевой ветви» B2 ‘.
который будет требовать файлы локальной версии как OK.
Вы можете запустить его для одного файла или целых каталогов проектов.
Мне просто удалось вклинить себя довольно тщательно, пытаясь следовать совету user619330 выше. Ситуация была: (1): я добавил некоторые файлы во время работы над моей начальной ветвью branch1; (2) я создал новую ветвь branch2 для дальнейшего развития, отделив ее от ствола, а затем объединив мои изменения с branch1 (3) сотрудник скопировал мои моды из branch1 в свою собственную ветвь, добавил дополнительные моды, а затем слился обратно в ствол; (4) Теперь я хотел объединить последние изменения из trunk в мою текущую рабочую ветвь, branch2. Это с svn 1.6.17.
слияние имело конфликты дерева с новыми файлами, и я хотел, чтобы новая версия из ствола, где они отличались, поэтому из чистой копии branch2 я сделал svn-удаление конфликтующих файлов, совершил эти изменения branch2 (таким образом, создав временную версию branch2 без рассматриваемых файлов), а затем сделал мое слияние из ствола. Я сделал это, потому что хотел, чтобы история соответствовала версия магистрали, чтобы у меня не было больше проблем позже при попытке объединить обратно в магистраль. Слияние прошло хорошо, я получил транковую версию файлов, svn st показывает все в порядке, а затем я нажал больше конфликтов дерева, пытаясь зафиксировать изменения, между удалением, которое я сделал ранее, и добавлением из слияния. Сделал svn разрешение конфликтов в пользу моей рабочей копии (которая теперь имела транковую версию файлов) и получил ее для фиксации. Все должно быть хорошо, верно?
SVN — разрешение конфликтов
Том решает добавить файл README для своего проекта. Поэтому он создает файл README и добавляет в него список TODO. После добавления этого файла хранилище находится в редакции 6.
Джерри проверяет последний код, который находится в редакции 6. И сразу же он начинает работать. Через несколько часов Том обновляет файл README и фиксирует свои изменения. Модифицированный README будет выглядеть следующим образом.
Сейчас хранилище находится на 7-й редакции, а рабочая копия Джерри устарела. Джерри также обновляет файл README и пытается зафиксировать свои изменения.
Файл README Джерри выглядит следующим образом.
Шаг 1: Просмотр конфликтов
Subversion обнаружила, что файл README изменился с момента последнего обновления. Итак, Джерри должен обновить свою рабочую копию.
Subversion жалуется, что существует конфликт с файлом README, и Subversion не знает, как решить эту проблему. Поэтому Джерри выбирает опцию df для рассмотрения конфликта.
Шаг 2: отложить конфликты
После открытия README в текстовом редакторе он понимает, что Subversion включил и код Тома, и его код с маркерами конфликта.
Джерри хочет изменений Тома так же, как и его, поэтому он просто удаляет строки, содержащие маркеры конфликта.
Итак, модифицированный файл README будет выглядеть следующим образом.
Джерри разрешил конфликт и он повторил коммит.
Шаг 3: Разрешить конфликты
В приведенном выше коммите буква C указывает на наличие конфликта в файле README. Джерри разрешил конфликт, но не сказал Subversion, что он разрешил конфликт. Он использует команду разрешения, чтобы сообщить Subversion о разрешении конфликта.
Почему я получаю конфликты дерева в Subversion?
Я не думаю, что они должным образом помечены.
11 ответов:
Я нашел решение, читая ссылку, которую дал Гэри (и я предлагаю следовать этому пути).
подведение итогов для разрешения конфликта дерева фиксация рабочего каталога С клиентом SVN 1.6.X вы можете использовать:
предупреждение:«фиксация рабочего каталога» означает, что ваша структура песочницы будет той, которую вы фиксируете, так что если, например, вы удалил некоторые файлы из вашей песочницы они будут удалены из репозитория тоже. Это относится только к конфликтующему каталогу.
в TortoiseSVN, выбрав» Resolved » по щелчку правой кнопкой мыши, фактически решает эту проблему.
в блоге Subversion CollabNet есть отличная статья о Конфликты Дерево.
по моему опыту, SVN создает конфликт дерева всякий раз, когда я удаляю папку. Кажется, нет никакой причины.
Я не могу ждать, чтобы переключиться на Git.
Я не знаю, происходит ли это с вами, но иногда я выбираю неправильный каталог для слияния, и я получаю эту ошибку, хотя все файлы выглядят совершенно нормально.
Это может быть глупая ошибка, но это не всегда очевидно, потому что вы думаете, что это что-то более сложное.
здесь происходит следующее: Вы создаете новый файл на своем стволе, а затем объединяете его в свою ветку. В фиксации слияния этот файл также будет создан в вашей ветке.
когда вы объединяете свою ветвь обратно в магистраль, SVN пытается сделать то же самое снова: он видит, что файл был создан в вашей ветви, и пытается создать его в вашей магистрали в фиксации слияния, но он уже существует! Это создает конфликт дерева.
после реинтеграции ветки настоятельно рекомендуется удалить ее, в противном случае вы будете держать получение treeconflicts всякий раз, когда вы сливаетесь в другом направлении: от ствола до вашей ветви. (По той же самой причине, что и описанная выше.)
есть способ обойти это тоже, но я никогда не пробовал. Вы можете прочитать его в этом посте:Subversion отделение реинтеграции в v1. 6
Это может быть вызвано тем, что не используются одни и те же версии клиентов на всем протяжении.
использование клиента версии 1.5 и клиента версии 1.6 для одного и того же репозитория может создать такую проблему. (Меня самого только что укусили.)
Если вы столкнулись с конфликтами дерева, которые не имеют смысла, потому что вы не редактировали/удаляли/не подходили к файлу, есть также хороший шанс, что в команде слияния произошла ошибка.
Что может произойти, так это то, что вы ранее уже объединили кучу изменений, которые вы включаете в свое текущее слияние. Например, в trunk кто-то отредактировал файл, а затем позже переименовал его. Если в первом слиянии вы включаете редактирование, а затем во втором слиянии включите оба редактирование и переименование (по сути, удаление), это также даст вам конфликт дерева. Причина этого заключается в том, что ранее Объединенное редактирование появляется как ваше собственное, и поэтому удаление не будет выполняться автоматически.
Это может произойти на 1.4 репозиториях по крайней мере, я не уверен, помогает ли здесь mergetracking, введенный в 1.5.
Я тоже столкнулся с этой проблемой сегодня, хотя моя конкретная проблема, вероятно, не связана с вашей. Изучив список файлов, я понял, что я сделал-я временно использовал файл в одной сборке из другой сборки. Я внес в него много изменений и не хотел, чтобы история SVN была сиротой, поэтому в своей ветке я переместил файл из папки другой сборки. Это не отслеживается SVN, поэтому он просто выглядит как файл удаляется, а затем повторно добавляется. Это в конечном итоге вызывает конфликт дерева.
Я решил проблему, переместив файл обратно, фиксации и затем слияние моей ветке. Затем я переместил файл обратно после этого. 🙂 Это, казалось, делало трюк.
у меня была похожая проблема. Единственное, что на самом деле работало для меня, это удалить конфликтующие подкаталоги с:
затем скопируйте их снова из другого корневого каталога в рабочую копию, которая имеет их с:
вы можете получить предупреждения с последним, но просто игнорировать их и, наконец,
У меня была такая же проблема, и я решил ее, повторно выполнив слияние с помощью эти инструкции. В основном, он использует SVN «2-URL merge» для обновления trunk к текущему состоянию вашей ветви, не беспокоясь так много об истории и конфликтах деревьев. Спас меня от ручного исправления 114 конфликтов дерева.
Я не уверен, что он сохраняет историю так же хорошо, как хотелось бы, но в моем случае это стоило того.
сценарий, с которым я иногда сталкиваюсь:
предположим, что у вас есть магистраль, из которой вы создали ветку выпуска. После некоторых изменений в магистрали (в частности, создания каталога» some-dir») вы создаете ветку feature/fix, которую вы хотите позже объединить в ветку release (потому что изменения были достаточно малы, и функция/исправление важна для выпуска).
Если вы затем попытаетесь объединить ветку feature/fix непосредственно в ветку release, вы получите конфликт дерева (хотя каталог даже не существовал в ветке feature/fix):
поэтому вам нужно явно объединить коммиты, которые были сделаны на транке перед созданием ветви feature/fix, которая создала каталог «some-dir» перед слиянием ветви feature/fix.
Я часто забываю, что как то не надо в git.
Why am I getting tree conflicts in Subversion?
I had a feature branch of my trunk and was merging changes from my trunk into my branch periodically and everything was working fine. Today I went to merge the branch back down into the trunk and any of the files that were added to my trunk after the creation of my branch were flagged as a «tree conflict». Is there a way to avoid this in the future?
I don’t think these are being properly flagged.
12 Answers 12
I found the solution reading the link that Gary gave (and I suggest to follow this way).
Summarizing to resolve the tree conflict committing your working directory with SVN client 1.6.x you can use:
WARNING: «Committing your working directory» means that your sandbox structure will be the one you are committing, so if, for instance, you deleted some file from your sandbox they will be deleted from the repository too. This applies only to the conflicted directory.
In TortoiseSVN, selecting «Resolved» on right click, actually resolves this issue.
Subversion 1.6 added Tree Conflicts to cover conflicts at the directory level. A good example would be when you locally delete a file then an update tries to bring a text change down on that file. Another is when you you have a subversion Rename of a file you are editing since that is an Add/Delete action.
CollabNet’s Subversion Blog has a great article on Tree Conflicts.
In my experience, SVN creates a tree conflict WHENEVER I delete a folder. There appears to be no reason.
I can’t wait to switch to Git.
I don’t know if this is happening to you, but sometimes I choose the wrong directory to merge and I get this error even though all the files appear completely fine.
This might be a stupid mistake, but it’s not always obvious because you think it’s something more complicated.
What’s happening here is the following: You create a new file on your trunk, then you merge it into your branch. In the merge commit this file will be created in your branch also.
When you merge your branch back into the trunk, SVN tries to do the same again: It sees that a file was created in your branch, and tries to create it in your trunk in the merge commit, but it already exists! This creates a tree conflict.
After reintegrating a branch it is highly advisable to remove it, otherwise you will keep getting treeconflicts whenever you merge in the other direction: from the trunk to your branch. (For exactly the same reason as described before.)
There is a way around this too, but I never tried it. You can read it in this post: Subversion branch reintegration in v1.6
This can be caused by not using the same version clients all over.
Using a version 1.5 client and a version 1.6 client towards the same repository can create this kind of problem. (I was just bitten myself.)
Until today, for since at least 3 months ago, I regularly encountered hundreds of tree conflicts when attempting to merge a branch back into the trunk (using TortoiseSVN 1.11). Whether rebased or not, BTW. I’ve been using TortoiseSVN since its v1, back in 2004, and I used to reintegrate branches all the time. Something must have happened recently I suppose?
So today I ran this simple experiment, and I found what was creating these crazy conflicts:
Discussion: (see attachment)
all revisions. of what? Little did I know that the client must have been referring to «all revisions of the target! (trunk)», as, in the process of reintegrating that branch, I saw the mention «Merging revisions 1-HEAD»! OMG. Poor Devil, you’re falling to your death here. That branch was born @393, can’t you read its birth certificate, for God’s sake? 
Resolution:
Moral: I can’t comprehend why they still haven’t fixed that bug, because it is one, I’m sorry. I should take the time to report this with them.
Не удается разрешить конфликт дерева с SVN
Недавно я встретил очень странное поведение подрывной деятельности.
Я только что объединил свою локальную копию ветки с удаленной ветвью. Все прошло гладко, но у меня есть один конфликт дерева (локальное удаление, удаленное обновление).
Subversion сообщила, что она разрешила мои проблемы, и «svn st» больше не показывал никаких проблем. Итак, я попытался зафиксировать, но svn сказал мне, что одна из внутренних папок (внутри моей противоречивой) устарела и предложила svn вверх, НО она заставила папку снова в конфликте!
Что мне делать, чтобы выбраться из этого зрительного круга?
ОТВЕТЫ
Ответ 1
Это может или не поможет, но иногда «svn cleanup» исправляет странные проблемы с метаданными. Если вы проверите чистую рабочую копию, имеет ли чистая копия такая же проблема? Если это так, то предыдущий ответ звучит как шаг в правильном направлении
Ответ 2
Надеемся на эту помощь
Ответ 3
Вы можете использовать другой способ, чем команда разрешения svn:
Ответ 4
Вероятно, вы не обновляли свои папки, когда вы делали слияние, или был конфликт где-то до слияния. Чтобы исправить это, вам нужно будет вернуть свою сундук (целевую папку) в предыдущую ревизию. Затем запустите очистку в этой папке. Затем запустите очистку в папке ветки (исходная папка). Затем обновите обе папки снова. Если вы получаете строки красным цветом в любом рабочем процессе, вам нужно сначала вернуть эти файлы, а затем ввести их в состояние, в котором вы хотите. Затем обновите папки (да, еще раз). Наконец, снова выполните слияние.
Ответ 5
Это то, что сработало для меня, чтобы отказаться от всех локальных изменений и перейти с файлами из репозитория сервера:
Появится это сообщение: W155027: конфликт дерева может быть разрешен только «работающим»
Неинтуитивный следующий шаг, но это фактически сокращает catch-22:
СЕЙЧАС вернет все «рабочие» изменения рекурсивно. Это уменьшило все мои локальные изменения.
Возврат к нормальному состоянию без ошибок: