为什么在Subversion中出现树冲突？

我的主干上有一个功能分支，并且正在定期将主干中的更改合并到我的分支中，并且一切正常。今天，我去将分支合并回主干，创建分支后添加到主干的任何文件都标记为“树冲突”。有没有办法避免将来发生这种情况？

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

我找到了阅读Gary给出的链接的解决方案（我建议按照这种方式）。

总结一下使用SVN客户端1.6.x 提交工作目录来解决树冲突的方法，您可以使用：

svn resolve --accept working -R .

.冲突的目录在哪里。

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

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

在TortoiseSVN中，右键单击选择“已解决”实际上可以解决此问题。

Subversion 1.6添加了“树冲突”以涵盖目录级别的冲突。一个很好的例子是，当您在本地删除文件然后进行更新时，试图对该文件进行文本更改。另一个是当您拥有正在编辑的文件的Subversion重命名时，这是一个Add / Delete操作。

CollabNet的Subversion博客上有一篇有关树冲突的精彩文章。

以我的经验，每当我删除文件夹时，SVN都会创建树冲突。似乎没有理由。

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

我等不及要切换到Git了。

我应该澄清-我使用Subclipse。那可能是问题所在！同样，我等不及要切换了...

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

例：

将/ svn / Project / branch / some-branch / Sources合并到/ svn / Project / trunk --->树冲突

合并/ svn / Project / branch / some-branch到/ svn / Project / trunk --->确定

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

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

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

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

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

但是，将分支合并回主干时，基础数学却大不相同。现在，您的功能分支是重复的主干更改和私有分支更改的混搭，因此没有简单连续的修订范围可以复制。通过指定--reintegrate选项，您要求Subversion仅仔细复制分支唯一的那些更改。（实际上，它是通过将最新的主干树与最新的分支树进行比较来完成此操作的：所产生的差异正是您的分支更改！）

重新集成分支后，强烈建议删除它，否则，无论何时从另一个方向合并（从干线到分支），您都将不断遇到树冲突。（由于与上述完全相同的原因。）

也可以解决此问题，但我从未尝试过。您可以在这篇文章中阅读它：v1.6中的Subversion分支重新集成

这可能是由于未完全使用相同版本的客户端引起的。

对相同的存储库使用1.5版客户端和1.6版客户端会产生这种问题。（我只是被自己咬了。）

如果遇到树冲突，由于没有在文件附近的任何位置进行编辑/删除/复制而没有意义，那么合并命令中也很可能出现错误。

可能发生的情况是，您先前已经合并了当前合并中要包含的一堆更改。例如，在主干中，有人编辑了一个文件，然后稍后对其重命名。如果在第一次合并中包含编辑，然后在第二次合并中同时包含编辑和重命名（本质上是删除），则还会产生树冲突。原因是先前合并的编辑然后显示为您自己的，因此删除不会自动执行。

至少在1.4版本的存储库中可能会发生这种情况，我不确定1.5版本中引入的mergetracking是否对您有所帮助。

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

因此，今天我进行了一个简单的实验，发现了造成这些疯狂冲突的原因：

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

讨论：（请参阅附件）

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

解析度：

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

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

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

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

我有一个类似的问题。唯一对我有用的方法是使用以下命令删除冲突的子目录：

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个树冲突。

我不确定它是否能像人们想要的那样保存历史，但是就我而言，这是值得的。

我有时遇到的一种情况：

假设您有一个主干，从中创建了一个发布分支。在主干上进行了一些更改（特别是创建“ 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

因此，您需要在合并功能部件/修订版分支之前，显式地合并在主干上完成的提交，然后再创建功能部件/修订版分支，该分支创建了“ some-dir”目录。

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