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

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

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

当您将分支合并回中继中时，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分支重新整合

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.

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

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

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

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

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

我通过Gary给出的链接找到了解决方案(我建议按照这种方式进行)。

通过汇总来解决向SVN客户端1.6提交工作目录的树冲突。X你可以使用:

svn resolve --accept working -R .

在哪里。目录冲突。

警告:“提交你的工作目录”意味着你的沙盒结构将是你要提交的，因此，例如，如果你从你的沙盒中删除了一些文件，它们也会从存储库中删除。这只适用于冲突的目录。

通过这种方式，我们建议SVN解决冲突(——resolve)，从当前目录(.)开始递归地(-R)接受沙箱中的工作副本(——accept working)。

在TortoiseSVN中，右键单击“Resolved”，实际上解决了这个问题。