为什么我在Subversion中得到树冲突?

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

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

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

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

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

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

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

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

例子:

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

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

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

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

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

我今天也遇到了这个问题，虽然我的问题可能和你的没有关系。在检查了文件列表之后，我意识到自己做了什么——我临时在一个程序集中使用了另一个程序集中的文件。我对它做了很多更改，不想孤立SVN历史记录，所以在我的分支中，我将该文件从其他程序集的文件夹中移动过来。SVN不会跟踪这一点，因此看起来就像删除了文件，然后重新添加了文件。这最终导致树冲突。

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

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

总结解决树冲突提交工作目录与SVN客户端1.6。X你可以使用:

svn resolve --accept working -R .

其中.是冲突目录。

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

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

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

我也遇到过类似的问题。唯一对我有用的是删除冲突的子目录:

svn delete --force ./SUB_DIR_NAME

然后从工作副本的另一个根目录中再次复制它们:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

而且

svn add *

你可能会得到最后一个警告，但忽略它们，最后

svn ci .

我也有同样的问题，并通过使用这些指令重新做合并来解决它。基本上，它使用SVN的“2-URL合并”将trunk更新为分支的当前状态，而不用担心历史和树冲突。让我不用手动修复114棵树的冲突。

我不确定它是否像人们希望的那样保存了历史，但对我来说是值得的。

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

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

避免这种情况的方法是做一个特殊的合并，重返社会。你可以通过--reintegrate开关来实现这一点。

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

当将分支合并回主干时，底层的 数学是完全不同的。你的功能分支现在是一个大杂烩 重复的主干变更和私有分支变更，所以 没有简单的连续修订范围可以复制。通过 指定——reintegration选项，则要求Subversion执行 小心地只复制那些对您的分支独特的更改。(在 事实上，它通过比较最新的树干和最新的树干来做到这一点 分支树:结果的差异正是你的分支变化!)

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

其实也有办法，但我从没试过。你可以在这篇文章中阅读: 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中是不必要的。

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

1. 我叉开了后备箱@393;
2. 我随机修改了几十个文件，也创建了新的文件;
3. 我承诺。现在@395(一名同事花了394美元去表演自己的作品)。
然后我尝试将分支重新集成到主干中，仅用于测试; 按照TortoiseSVN在向导中的建议:“要合并所有修订(重新集成)，请将该框保留为空”。为了实现这一点，我右键单击到trunk文件夹，并选择“TortoiseSVN > Merge, from /path/ To /branch”，然后我使转速范围为空，就像对话框中建议的那样

讨论:(见附件)

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

解决方法:

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

< >强道德: 我不能理解为什么他们还没有修复这个错误，因为这是一个，对不起。