如果因为没有编辑/删除/接近文件而遇到树冲突，那么合并命令中也很有可能出现错误。

可能发生的情况是，您之前已经合并了当前合并中包含的一些更改。例如，在trunk中有人编辑了一个文件，然后重新命名它。如果在第一次合并中包含编辑，然后在第二次合并中同时包含编辑和重命名(本质上是删除)，它也会给您一个树冲突。这样做的原因是，先前合并的编辑将显示为您自己的编辑，因此删除将不会自动执行。

这至少可以发生在1.4版本的存储库中，我不确定1.5版本中引入的合并跟踪在这里是否有帮助。

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.

我通过将文件移回，提交，然后合并我的分支来解决这个问题。然后我把文件移了回来。:)这似乎奏效了。

我不知道这是否发生在你身上，但有时我选择了错误的目录合并，我得到这个错误，即使所有的文件看起来完全正常。

例子:

合并/ svn /项目/部门/分公司/来源 to /svn/Project/trunk——>树冲突

合并/ svn /项目/部门/分公司 to /svn/Project/trunk——> OK

这可能是一个愚蠢的错误，但它并不总是显而易见的，因为你认为它是更复杂的东西。

这可能是由于没有在所有地方使用相同版本的客户端造成的。

使用版本1.5的客户端和版本1.6的客户端使用同一个存储库会产生这种问题。(我自己也被咬了。)

如果因为没有编辑/删除/接近文件而遇到树冲突，那么合并命令中也很有可能出现错误。

可能发生的情况是，您之前已经合并了当前合并中包含的一些更改。例如，在trunk中有人编辑了一个文件，然后重新命名它。如果在第一次合并中包含编辑，然后在第二次合并中同时包含编辑和重命名(本质上是删除)，它也会给您一个树冲突。这样做的原因是，先前合并的编辑将显示为您自己的编辑，因此删除将不会自动执行。

这至少可以发生在1.4版本的存储库中，我不确定1.5版本中引入的合并跟踪在这里是否有帮助。

Subversion 1.6添加了树冲突来覆盖目录级别的冲突。一个很好的例子是，当您在本地删除一个文件时，更新会尝试对该文件进行文本更改。另一种情况是，当您对正在编辑的文件进行subversion重命名时，因为这是一个添加/删除操作。

CollabNet的Subversion博客上有一篇关于树冲突的很棒的文章。