我的主干有一个功能分支，并且定期将主干中的更改合并到我的分支中，一切正常。今天我将分支合并回主干，在创建分支后添加到我的主干的任何文件都被标记为“树冲突”。将来有没有办法避免这种情况？
我认为这些都没有被正确标记。
问问题
289031 次
12 回答
403
我找到了阅读 Gary 给出的链接的解决方案（我建议按照这种方式进行操作）。
总结以解决使用 SVN 客户端 1.6.x提交工作目录的树冲突，您可以使用：
svn resolve --accept working -R .
.冲突的目录在哪里。
警告：“提交您的工作目录”意味着您的沙箱结构将是您提交的那个，因此，例如，如果您从沙箱中删除了一些文件，它们也会从存储库中删除。这仅适用于冲突目录。
通过这种方式，我们建议 SVN 解决冲突（--resolve），接受沙箱中的工作副本（--accept working），递归地（-R），从当前目录（.）开始。
在 TortoiseSVN 中，右键单击选择“已解决”，实际上解决了这个问题。
于 2010-09-16T16:31:53.340 回答
61
Subversion 1.6 添加了树冲突来覆盖目录级别的冲突。一个很好的例子是，当您在本地删除文件时，更新会尝试对该文件进行文本更改。另一个是当您对正在编辑的文件进行颠覆重命名时，因为这是一个添加/删除操作。
CollabNet 的 Subversion 博客有一篇关于树冲突的精彩文章。
于 2009-04-10T18:08:51.327 回答
28
我不知道这是否发生在你身上，但有时我选择了错误的目录来合并，即使所有文件看起来都很好，我也会收到这个错误。
例子：
合并 /svn/Project/branches/some-branch/Sources 到 /svn/Project/trunk ---> 树冲突
合并 /svn/Project/branches/some-branch 到 /svn/Project/trunk ---> OK
这可能是一个愚蠢的错误，但它并不总是很明显，因为你认为它更复杂。
于 2010-04-14T17:38:48.830 回答
17
这里发生的情况如下：您在主干上创建一个新文件，然后将其合并到您的分支中。在合并提交中，该文件也将在您的分支中创建。
当您将分支合并回主干时，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
于 2015-01-16T13:36:33.980 回答
7
这可能是由于没有完全使用相同版本的客户端造成的。
对同一存储库使用 1.5 版客户端和 1.6 版客户端可能会产生此类问题。（我自己也被咬了。）
于 2010-04-02T10:58:36.670 回答
5
直到今天，至少从 3 个月前开始，我在尝试将分支合并回树干时经常遇到数百个树冲突（使用TortoiseSVN 1.11）。顺便说一句，无论是否重新定位。从 2004 年的 v1 开始，我一直在使用 TortoiseSVN，而且我一直在重新集成分支。我想最近一定发生了什么事吧？
所以今天我做了这个简单的实验，我发现是什么造成了这些疯狂的冲突：
- 我从树干上分叉了@393；
- 我随机修改了数十个文件，以及创建了新文件；
- 我答应了。现在@395（一位同事在 394 分叉去做他自己的事情）。
- 然后我尝试将分支重新集成回主干，仅测试；遵循 TortoiseSVN 在向导中的建议：“要合并所有修订（重新集成），请将该框留空”。为此，我右键单击主干文件夹，然后选择“TortoiseSVN > Merge, from /path/to/branch”，然后按照对话框中的建议将转速范围留空。
讨论：（见附件）
所有的修订......什么？我几乎不知道客户端一定是指“目标的所有修订版！（主干）”，因为在重新集成该分支的过程中，我看到了“合并修订版 1-HEAD”！我的天啊。可怜的恶魔，你在这里摔死了。那个分支诞生于@393，看在上帝的份上，你看不到它的出生证明吗？
解析度：
- 与向导的建议相反，请指定一个范围，涵盖...分支生命的所有修订！因此，394-HEAD；
- 现在再次运行该合并测试，并获得一支雪茄。(
)。
道德： 我无法理解为什么他们仍然没有修复那个错误，因为它是一个，我很抱歉。我应该花时间向他们报告这件事。
于 2019-05-22T04:21:57.083 回答
4
如果您遇到没有意义的树冲突，因为您没有编辑/删除/来到文件附近的任何地方，那么合并命令中也很有可能出现错误。
可能发生的情况是，您之前已经合并了您当前合并中包含的一堆更改。例如，在主干中，有人编辑了一个文件，然后重命名了它。如果在第一次合并中包含编辑，然后在第二次合并中包含编辑和重命名（本质上是删除），它也会给你一个树冲突。这样做的原因是先前合并的编辑会显示为您自己的，因此不会自动执行删除。
这至少可以在 1.4 存储库中发生，我不确定 1.5 中引入的合并跟踪是否有帮助。
于 2009-08-20T06:55:07.303 回答
1
我今天也遇到了这个问题，尽管我的特定问题可能与您的问题无关。检查文件列表后，我意识到我做了什么——我暂时在一个程序集中使用另一个程序集中的文件。我对其进行了很多更改，并且不想孤立 SVN 历史记录，因此在我的分支中，我将文件从另一个程序集的文件夹中移了过来。这不是 SVN 跟踪的，所以看起来文件被删除然后重新添加。这最终导致了树冲突。
我通过将文件移回，提交，然后合并我的分支来解决问题。然后我把文件移回来了。:) 这似乎奏效了。
于 2010-09-03T16:02:26.667 回答
1
我有一个类似的问题。唯一对我有用的是删除冲突的子目录：
svn delete --force ./SUB_DIR_NAME
然后再次从包含它们的工作副本中的另一个根目录中复制它们：
svn copy ROOT_DIR_NAME/SUB_DIR_NAME
然后做
svn cleanup
和
svn add *
您可能会收到最后一个警告，但请忽略它们，最后
svn ci .
于 2012-01-20T15:38:13.453 回答
0
我遇到了同样的问题，并通过使用这些说明重新进行合并来解决它。基本上，它使用 SVN 的“2-URL 合并”来更新trunk您分支的当前状态，而无需过多关注历史记录和树冲突。使我免于手动修复 114 个树冲突。
我不确定它是否像人们想要的那样保留了历史，但就我而言，这是值得的。
于 2012-04-04T20:14:30.120 回答
0
我有时会遇到的一个场景：
假设您有一个主干，您从中创建了一个发布分支。在对主干进行一些更改（特别是创建“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 中是不必要的。
于 2017-09-01T12:42:58.650 回答