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

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

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

svn resolve --accept working -R .

其中 . 是冲突的目录。

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

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

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

---

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

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

---

以我的经验，当我删除文件夹时，SVN 会产生树冲突。似乎没有任何理由。

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

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

我应该澄清一下 - 我使用 Subclipse。这大概就是问题所在！再一次，我迫不及待地想换...

---

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

例子：

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

合并 /svn/Project/branches/some-branch 到 /svn/Project/trunk ---> OK

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

---

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

当您将分支合并回主干时，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

---

这可能是由于没有完全使用相同版本的客户端造成的。

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

---

直到今天，至少从 3 个月前开始，我在尝试将分支合并回树干时经常遇到数百个树冲突（使用 TortoiseSVN 1.11）。顺便说一句，无论是否重新定位。从 2004 年的 v1 开始，我一直在使用 TortoiseSVN，而且我一直在重新集成分支。我想最近一定发生了什么事吧？

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

我从树干上分叉了@393；我随机修改了数十个文件，以及创建了新文件；我答应了。现在@395（一位同事在 394 分叉去做他自己的事情）。然后我尝试将分支重新集成回主干，仅测试；按照向导中 TortoiseSVN 的建议：“要合并所有修订（重新集成），请将该框留空”。为此，我右键单击主干文件夹，然后选择“TortoiseSVN > Merge, from /path/to/branch”，然后按照对话框中的建议将转速范围留空。

讨论：（见附件）

https://i.stack.imgur.com/CuJQu.png

解析度：

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

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

---

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

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

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

---

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

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

---

我有一个类似的问题。唯一对我有用的是删除冲突的子目录：

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

和

svn add *

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

svn ci .

---

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

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

---

我有时会遇到的一个场景：

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

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

如果您随后尝试将 feature/fix 分支直接合并到 release 分支中，您将遇到树冲突（即使该目录甚至在 feature/fix 分支中都不存在）：

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

因此，您需要在创建功能/修复分支之前明确合并在主干上完成的提交，该分支在合并功能/修复分支之前创建了“some-dir”目录。

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

---