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

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

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

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

根据我的经验，每当我删除一个文件夹时，SVN都会产生树冲突。似乎没有什么理由。

我是唯一一个工作在我的代码->删除目录->提交->冲突!

我迫不及待地想切换到Git。

我应该澄清一下，我使用Subclipse。这可能就是问题所在!再说一次，我迫不及待地想换……

直到今天，至少从3个月前开始，我在尝试将一个分支合并回主干(使用TortoiseSVN 1.11)时经常遇到数百个树冲突。顺便说一句，不管是否重制。 我从2004年的TortoiseSVN v1开始就一直在使用它，而且我一直在重新集成分支。我想最近一定发生了什么事吧?

所以今天我做了一个简单的实验，我发现了是什么导致了这些疯狂的冲突:

I forked off the trunk @393; I modified tens of files randomly, as well as creating new ones; I committed. Now @395 (a colleague forked off at 394 to perform his own stuff). Then I tried to reintegrate the branch back into the trunk, test only; 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.

讨论:(见附件)

所有修改……的什么?我不知道客户肯定指的是“所有修订的目标!”(主干)”，因为，在重新集成该分支的过程中，我看到提到“合并修订1-HEAD”!我的天啊可怜的魔鬼，你会死在这里的。那个分支是@393出生的，看在上帝的份上，你看不懂它的出生证明吗?

解决方法:

与wiz的建议相反，请指定一个范围，涵盖…的所有修订。树枝的生命!因此,394头; 现在再次运行合并测试，并获得一支雪茄。()。

道德: 我不能理解为什么他们还没有修复这个错误，因为这是一个，对不起。 我应该花时间跟他们汇报。

我有时会遇到这样的情况:

假设您有一个主干，从中创建了一个发布分支。在主干上做了一些更改之后(特别是创建“some-dir”目录)，你创建了一个特性/修复分支，你想稍后将其合并到发布分支中(因为更改足够小，而且特性/修复对于发布非常重要)。

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

如果你尝试将特性/修复分支直接合并到发布分支中，你会得到一个树冲突(即使目录甚至不存在于特性/修复分支中):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

因此，在创建feature/fix分支之前，你需要显式地合并在trunk上完成的提交，该分支在合并feature/fix分支之前创建了“some-dir”目录。

我经常忘记这一点，因为这在git中是不必要的。

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.

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