Question

我的行李箱有一个功能分支，并且定期将我的行李箱的变化合并到我的分支机构中，一切正常。今天我将分支合并回到主干中，并且在创建分支后添加到我的主干的任何文件被标记为“树冲突”。有没有办法在将来避免这种情况？

我认为这些都没有被正确标记。

Answer 1

我发现解决方案正在阅读Gary给出的链接（我建议按照这种方式）。

总结解决树冲突提交工作目录与SVN客户端1.6.x，您可以使用：

svn resolve --accept working -R .

其中.是冲突目录。

警告：“提交您的工作目录”意味着您的沙箱结构将是您提交的那个，因此，例如，如果您从沙箱中删除了某个文件，那么它们将是也从存储库中删除。这仅适用于冲突目录。

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

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

Answer 2

Subversion 1.6添加了Tree Conflicts以涵盖目录级别的冲突。一个很好的例子就是当你在本地删除文件时，更新会尝试将文本更改为该文件。另一个是当你有一个正在编辑的文件的subversion重命名，因为这是一个添加/删除操作。

CollabNet的Subversion博客上有一篇关于Tree Conflicts的精彩文章。

Answer 3

根据我的经验，SVN会在删除文件夹时创建树冲突。似乎没有理由。

我是唯一一个处理我的代码的人 - ＆gt;删除目录 - ＆gt;提交 - ＆gt;冲突！

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

我应该澄清 - 我使用Subclipse。那可能就是问题！再一次，我迫不及待想要切换......

Answer 4

我不知道你是否发生了这种情况，但有时我会选择错误的目录进行合并，即使所有文件看起来都很好，我也会收到此错误。

示例：

Merge / svn / Project / branches / some-branch / Sources to / svn / Project / trunk ---＆gt;树冲突

Merge / svn / Project / branches / some-branch to / svn / Project / trunk ---＆gt;行

这可能是一个愚蠢的错误，但它并不总是很明显，因为你认为它更复杂。

Answer 5

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

当您将分支合并回主干时，SVN会再次尝试执行相同操作：它会看到您的分支中创建了一个文件，并尝试在合并提交中在您的主干中创建它，但它已经存在！这会造成树冲突。

避免这种情况的方法是进行特殊合并，重新整合。您可以使用--reintegrate开关来实现此目的。

您可以在文档中阅读此内容： http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

然而，当你的分支合并回主干时，底层数学是完全不同的。您的功能分支现在是混搭重复的主干更改和私有分支更改，所以没有简单的连续修改版本可以复制。通过指定--reintegrate选项，您要求Subversion 仔细复制只有您的分支特有的更改。（并在事实上，它通过比较最新的树干树和最新的树干来做到这一点分支树：产生的差异正是你的分支变化！）

重新集成分支后，最好将其删除，否则每当您向另一个方向合并时，您将不断遇到树冲突：从主干到分支。（原因与前面描述的完全相同。）

也有办法解决这个问题，但我从未尝试过。您可以在以下文章中阅读： Subversion branch reintegration in v1.6

Answer 6

这可能是由于未使用相同版本的客户端造成的。

将1.5版客户端和1.6版客户端用于同一存储库可能会产生此类问题。（我自己被咬了。）

Answer 7

如果您遇到没有意义的树冲突，因为您没有编辑/删除/来到文件附近的任何地方，那么合并命令中也很可能出现错误。

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

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

Answer 8

我今天也遇到过这个问题，虽然我的特定问题可能与你的问题无关。在检查文件列表后，我意识到我做了什么 - 我暂时在另一个程序集的一个程序集中使用了一个文件。我对它进行了很多更改，并且不想孤立SVN历史记录，因此在我的分支中，我将文件移到了另一个程序集的文件夹中。这不是由SVN跟踪的，因此它看起来就像文件被删除然后重新添加。这最终导致树冲突。

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

Answer 9

我有类似的问题。对我来说唯一有效的方法是删除冲突的子目录：

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

和

svn add *

您可能会收到最后一个警告，但只是忽略它们，最后

svn ci .

Answer 10

我遇到了同样的问题，并通过使用these instructions重新进行合并来解决它。基本上，它使用SVN的“2-URL合并”将trunk更新为分支的当前状态，而不必过多关注历史和树冲突。保存我手动修复114树冲突。

我不确定它是否能保留历史记录，但在我的情况下这是值得的。

Answer 11

我有时遇到的情景：

假设您有一个主干，您从中创建了一个发布分支。在trunk上进行一些更改后（特别是创建＆＃34; some-dir＆＃34;目录），您创建了一个功能/修复分支，您希望稍后将其合并到发布分支中（因为更改足够小并且功能/修复对于释放很重要。）

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

因此，您需要在创建功能/修复分支之前显式合并在主干上完成的提交，这将创建＆＃34; some-dir＆＃34;合并功能/修复分支之前的目录。

我经常忘记，因为在git中没有必要。

Answer 12

直到今天，至少在三个月前，当我尝试将分支合并回主干时（使用 TortoiseSVN 1.11 ），我经常遇到数百棵树冲突。不管是否基于基准，BTW。从2004年的v1开始，我就一直在使用TortoiseSVN，而我一直都在重新整合分支。我想最近一定发生了什么事？

所以今天我进行了一个简单的实验，发现是什么造成了这些疯狂的冲突：

我在@ 393下车了。
我随机修改了数十个文件，并创建了新文件；
我承诺。现在@ 395（一位同事在394分叉来执行自己的任务）。
然后，我尝试将分支重新整合到主干中，仅进行测试；遵循向导中TortoiseSVN的建议：“要合并所有修订（重新集成），请将该框留空”。为此，我右键单击了trunk文件夹，然后选择“ TortoiseSVN>从/ path / to / branch合并”，然后按照对话框的建议将转速范围留空。

讨论：（请参阅附件）

所有修订 ...是什么？ 我几乎不知道，客户一定是在引用“ 目标的所有修订版！（主干）”，因为在重新集成该分支的过程中，我看到了提及“合并修订版1-HEAD”！我的天啊。可怜的恶魔，你在这里死了。该分支机构是@ 393出生的，看在上帝的份上，您不能阅读其出生证明吗？

解决方案：

与wiz的建议相反，请指定一个范围，该范围涵盖...分支生命的所有修订！因此， 394头;
现在再次运行合并测试，并获得一支雪茄。（）。

道德： 我无法理解为什么他们仍然没有修复该错误，因为很抱歉，这是一个错误。我应该花时间向他们报告。

为什么我在Subversion中遇到树冲突？

12 个答案: