为什么我在 Subversion 中遇到树冲突？
我的主干有一个功能分支，并且定期将主干的更改合并到我的分支中，一切都工作正常。 今天，我将分支合并回主干，创建分支后添加到主干的任何文件都被标记为“树冲突”。 将来有办法避免这种情况吗？
我认为这些没有被正确标记。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我的主干有一个功能分支，并且定期将主干的更改合并到我的分支中，一切都工作正常。 今天，我将分支合并回主干，创建分支后添加到主干的任何文件都被标记为“树冲突”。 将来有办法避免这种情况吗？
我认为这些没有被正确标记。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（12）
我找到了阅读加里提供的链接的解决方案（我建议按照这种方式操作）。
总结一下，使用 SVN 客户端 1.6.x 来解决树冲突提交工作目录，您可以使用：
其中
.是冲突的目录。警告：“提交您的工作目录”意味着您的沙箱结构将是您正在提交的结构，因此，例如，如果您从沙箱中删除了某些文件，它们将从沙箱中删除存储库也是如此。 这仅适用于冲突的目录。
通过这种方式，我们建议 SVN 解决冲突 (
--resolve)，接受沙箱内的工作副本 (--接受工作），从当前目录（.）开始递归（-R）。在TortoiseSVN中，右键单击“已解决”，实际上解决了这个问题。
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:
where
.is the directory in conflict.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 this way, we are suggesting SVN to resolve the conflict (
--resolve), accepting the working copy inside your sandbox (--accept working), recursively (-R), starting from the current directory (.).In TortoiseSVN, selecting "Resolved" on right click, actually resolves this issue.
Subversion 1.6 添加了树冲突来覆盖目录级别的冲突。 一个很好的例子是，当您在本地删除文件时，更新会尝试对该文件进行文本更改。 另一种情况是当您对正在编辑的文件进行颠覆重命名时，因为这是一个添加/删除操作。
CollabNet 的 Subversion 博客有一篇关于树冲突的精彩文章。
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.
根据我的经验，每当我删除文件夹时，SVN 都会产生树冲突。 似乎没有理由。
我是唯一一个在我的代码上工作的人 -> 删除目录-> 提交-> 冲突！
我迫不及待地想切换到 Git。
我应该澄清 - 我使用 Subclipse。 大概就是这个问题吧！ 再次，我迫不及待地想换...
In my experience, SVN creates a tree conflict WHENEVER I delete a folder. There appears to be no reason.
I'm the only one working on my code -> delete a directory -> commit -> conflict!
I can't wait to switch to Git.
I should clarify - I use Subclipse. That's probably the problem! Again, I can't wait to switch...
我不知道您是否遇到这种情况，但有时我选择了错误的目录进行合并，即使所有文件看起来都完全正常，我也会收到此错误。
示例：
合并 /svn/Project/branches/some-branch/Sources
到 /svn/Project/trunk ---> 树冲突
合并 /svn/Project/branches/some-branch
到 /svn/Project/trunk ---> 好吧，
这可能是一个愚蠢的错误，但它并不总是显而易见的，因为你认为它是更复杂的事情。
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.
Example:
Merge /svn/Project/branches/some-branch/Sources
to /svn/Project/trunk ---> Tree conflict
Merge /svn/Project/branches/some-branch
to /svn/Project/trunk ---> OK
This might be a stupid mistake, but it's not always obvious because you think it's something more complicated.
这里发生的情况如下：您在主干上创建一个新文件，然后将其合并到分支中。 在合并提交中，该文件也将在您的分支中创建。
当您将分支合并回主干时，SVN 会尝试再次执行相同的操作：它发现在您的分支中创建了一个文件，并尝试在合并提交中在主干中创建它，但它已经存在！ 这会产生树冲突。
避免这种情况的方法是进行特殊的合并，即重新集成。 您可以使用
--reintegrate开关来实现此目的。您可以在文档中阅读相关内容：
http://svnbook.red -bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
重新集成分支后，强烈建议将其删除，否则每当您沿另一个方向合并时（从主干到分支），您都会不断遇到树冲突。 （与之前描述的原因完全相同。）
也有一种解决方法，但我从未尝试过。 您可以在这篇文章中阅读：v1.6 中的 Subversion 分支重新集成
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.
The way to avoid this, is to do a special merge, a reintegration. You can achieve this with the
--reintegrateswitch.You can read about this in the documentation:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
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
这可能是由于未始终使用相同版本的客户端造成的。
对同一存储库使用版本 1.5 客户端和版本 1.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.)
直到今天，至少从 3 个月前开始，当我尝试将分支合并回主干时（使用 TortoiseSVN 1.11），我经常遇到数百个树冲突。 顺便说一句，无论是否重新调整基础。
我从 2004 年的 v1 版起就一直在使用 TortoiseSVN，而且我一直都在重新集成分支。 我想最近一定发生了什么事情吧？
所以今天我进行了这个简单的实验，我发现了造成这些疯狂冲突的原因：
按照 TortoiseSVN 在向导中的建议：“要合并所有修订（重新集成），请将该框留空”。 为了实现这一点，我右键单击 trunk 文件夹，然后选择“TortoiseSVN > Merge, from /path/to/branch”，然后按照对话框中的建议，将转速范围留空 。
讨论：（见附件）
所有修订...内容是什么？ 我几乎不知道客户一定是指“目标的所有修订版！（主干）”，因为在重新集成该分支的过程中，我看到提到“合并修订版 1-HEAD”！ 我的天啊。 可怜的魔鬼，你会摔死在这里。 那个分支出生于@393，看在上帝的份上，你难道看不到它的出生证明吗？
解决方案：
道德：
我无法理解为什么他们仍然没有修复这个错误，因为这是一个错误，我很抱歉。
我应该花时间向他们报告此事。
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:
following TortoiseSVN's recommendation in the wizard: "to merge all revisions (reintegrate), leave that box empty". To achieve this, I right-clicked onto the trunk folder, and chose "TortoiseSVN > Merge, from /path/to/branch", and I left the rev range empty, as advised on the dialog.
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.
如果您遇到没有意义的树冲突，因为您没有编辑/删除/到达文件附近的任何位置，那么合并命令中也很可能存在错误。
可能发生的情况是，您之前已经合并了当前合并中包含的一堆更改。 例如，在主干中，有人编辑了一个文件，然后又对其进行了重命名。 如果在第一次合并中包含编辑，然后在第二次合并中包含编辑和重命名（本质上是删除），它也会给您带来树冲突。 原因是之前合并的编辑随后显示为您自己的编辑，因此不会自动执行删除。
这至少会发生在 1.4 存储库上，我不确定 1.5 中引入的合并跟踪是否有帮助。
If you encounter tree conflicts which do not make sense because you didn't edit/delete/come anywhere near the file, there is also a good chance that there was an error in the merge command.
What can happen is that you previously already merged a bunch of the changes you are including in your current merge. For instance, in trunk someone edited a file, and then later renames it. If in your first merge you include the edit, and then in a second merge include both the edit and the rename (essentially a remove), it will also give you a tree conflict. The reason for this is that the previously merged edit then appears as your own, and thus the remove will not be performed automatically.
This can occur on 1.4 repositories at least, I'm not sure whether the mergetracking introduced in 1.5 helps here.
我今天也遇到了这个问题，尽管我的特定问题可能与您的问题无关。 检查文件列表后，我意识到我做了什么——我暂时在一个程序集中使用了另一个程序集中的文件。 我对它进行了很多更改，并且不想孤立 SVN 历史记录，因此在我的分支中，我已将文件从其他程序集的文件夹移过来。 SVN 不会跟踪此情况，因此看起来只是文件被删除然后重新添加。 这最终会导致树冲突。
我通过将文件移回、提交并然后合并我的分支解决了这个问题。 然后我把文件移回来了。 :) 这似乎成功了。
I came across this problem today as well, though my particular issue probably isn't related to yours. After inspecting the list of files, I realized what I had done -- I had temporarily been using a file in one assembly from another assembly. I have made lots of changes to it and didn't want to orphan the SVN history, so in my branch I had moved the file over from the other assembly's folder. This isn't tracked by SVN, so it just looks like the file is deleted and then re-added. This ends up causing a tree conflict.
I resolved the problem by moving the file back, committing, and then merging my branch. Then I moved the file back afterward. :) That seemed to do the trick.
我有类似的问题。 唯一对我有用的方法是删除冲突的子目录：
然后从包含它们的工作副本中的另一个根目录再次复制它们：
然后执行
，
您可能会收到最后一个警告，但忽略它们并最后
I had a similar problem. The only thing that actually worked for me was to delete the conflicted subdirectories with:
Then copy them again from another root directory in the working copy that has them with:
Then do
and
You might get warnings with the last one, but just ignore them and finally
我遇到了同样的问题，并通过使用这些说明重新进行合并来解决它。 基本上，它使用 SVN 的“2-URL 合并”将
trunk更新为分支的当前状态，而不必担心历史记录和树冲突。 让我免于手动修复 114 个树冲突。我不确定它是否能如人们所愿地保存历史，但就我而言这是值得的。
I had this same problem, and resolved it by re-doing the merge using these instructions. Basically, it uses SVN's "2-URL merge" to update
trunkto the current state of your branch, without bothering so much about history and tree conflicts. Saved me from manually fixing 114 tree conflicts.I'm not sure if it preserves history as well as one would like, but it was worth it in my case.
我有时会遇到的一个场景：
假设您有一个主干，您从中创建了一个发布分支。 在主干上进行一些更改（特别是创建“some-dir”目录）后，您创建一个功能/修复分支，您希望稍后将其合并到发布分支中（因为更改足够小，并且功能/修复对于发布很重要） 。
如果您尝试将 feature/fix 分支直接合并到发布分支中，您将遇到树冲突（即使该目录甚至不存在于 feature/fix 分支中）：
因此您需要显式合并在trunk 在创建 feature/fix 分支之前创建了“some-dir”目录，然后再合并 feature/fix 分支。
我经常忘记这一点，因为这在 git 中是不必要的。
A scenario which I sometimes run into:
Assume you have a trunk, from which you created a release branch. After some changes on trunk (in particular creating "some-dir" directory), you create a feature/fix branch which you want later merge into release branch as well (because changes were small enough and the feature/fix is important for release).
If you then try to merge the feature/fix branch directly into the release branch you will get a tree conflict (even though the directory did not even exist in feature/fix branch):
So you need to explicitly merge the commits which were done on trunk before creating feature/fix branch which created the "some-dir" directory before merging the feature/fix branch.
I often forget that as that is not necessary in git.