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

例子:

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

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

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

这里发生的事情如下:在主干上创建一个新文件，然后将它合并到分支中。在合并提交中，这个文件也将在分支中创建。

当您将分支合并回中继中时，SVN再次尝试做同样的事情:它看到分支中创建了一个文件，并试图在合并提交中在中继中创建它，但它已经存在!这就产生了树冲突。

避免这种情况的方法，是做一个特殊的合并，重新整合。您可以使用——reintegrate开关来实现这一点。

你可以在文档中读到: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

When merging your branch back to the trunk, however, the underlying mathematics are quite different. Your feature branch is now a mishmash of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)

在重新集成一个分支之后，非常明智的做法是将其移除，否则当您从另一个方向(从主干到分支)合并时，您将继续得到树冲突。(原因与之前描述的完全相同。)

其实也有办法，但我从没试过。你可以在这篇文章中阅读:v1.6中的Subversion分支重新整合

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

假设您有一个主干，从中创建了一个发布分支。在主干上做了一些更改之后(特别是创建“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中是不必要的。

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

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

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

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

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

直到今天，至少从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头; 现在再次运行合并测试，并获得一支雪茄。()。

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