为什么合并一系列修订与单独合并它们不同？

Question

我一直在努力了解 SVN 合并/重新集成，并阅读了以下文章/书籍：

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

我显然不太明白，因为我不明白为什么在合并回主干（反射/循环合并）中包括同步修订是一个问题 - 我确实看到了理由对于不排除修订。

如果trunk上的一行文件A被合并到branch上的文件A'中，然后又合并回trunk，那么A和A'肯定没有区别，所以不冲突？为什么“[合并] 主干中已经存在的更改”是一个问题？

我正在尝试复制冲突场景以尝试了解重新整合为我所做的一切，但更让我困惑的是这种场景：

1. 在主干 (r4) 上提交更改
2. 将 r4 合并到分支并提交 (r5)
3. 提交分支上的更改 (r6)
4. 通过以下任一方式将分支合并到主干：
   • 将修订范围 r5-r6 合并到主干 - 发生冲突，或
   • 将 r5 合并到主干，然后将 r6 合并到主干 - 不会发生冲突

我正在使用 SmartSVN 6.6 和 SVN 1.6。为什么与单独合并每个修订版相比，合并修订版范围时会产生不同的结果？最终，为什么包含反射合并是一个问题？

Answer 1

简答 基于我对颠覆合并行为的观察（不是书籍/源知识）：

1. 带有显式修订的合并似乎完全不知道早期的合并，并且会像您进行合并一样频繁地重新应用更改。

2. 没有任何修订范围的“常规”合并知道哪些修订已经合并（到目标分支）。通常不会应用两次更改。但是，它不会检查要合并的更改是否源自现在是合并目标的同一分支。发生这种情况时，它会进行某种上下文相关的合并，但冲突会更频繁地出现。

3. merge --reintegrate 能够检测到源自合并目标过去的更改，并且不会重新应用这些更改。不幸的是，重新集成仅适用于功能分支。

我尽量避免任何类型 1. 的合并。 2.“常规”类型的合并只能通过合并到一个方向来驯服。当您再次上下合并时，麻烦就开始了。 每当我需要像在功能分支场景中那样“交叉合并”时，我会使用合并类型 3。或带有修订阻止的樱桃采摘（显式修订范围与 --record-only 合并）

SVN 根本无法“盲目地”支持广泛的合并操作:)。没有 VCS 可以解决所有相互冲突的人类决策。

为什么 svn 合并冲突

其特殊“冲突性”的部分原因可以在颠覆历史中找到。在 SVN 1.5 之前，只有显式合并。您必须知道您已经合并了哪些修订范围，并根据该知识进行下一次合并，否则您描述的冲突将会发生。

1.5 之前的 SVN 中的合并如下所示：

（分支的 HEAD 版本为 510） svn合并-r500:510http://server.tld/branches/stable-1.0

下一个合并是：

（分支的 HEAD 版本为 520） svn合并-r510:520http://server.tld/branches/stable-1.0

此语法仍然有效且有效。

您可以阅读我在 svn 1.4 最佳实践中描述的内容：（注意，旧链接！）http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.track

随着 SVN 1.5 中引入的合并功能，它开始衡量您的一些意图。 例如，现在 SVN 将计算定义范围以自动合并并跟踪合并的内容。更少的开销，更少的人为错误导致的冲突。 但是当使用许多分支时，您仍然可能希望应用更改两次。 Subversion 保留了这种能力。

如何忍受它

您在 4 步示例中所做的樱桃采摘使您的树干和树枝保持“紧密”。在步骤 3 中，您的两个分支是相同的，因此在步骤 4 中合并不再有意义。 我知道你简化了，在现实世界的场景中会有更多的变化。但是颠覆分支的主要思想是分离。从不稳定、不兼容的开发、自定义构建中保持稳定...

樱桃挑选/交叉合并的需要通常只是对分支和分支使用策略考虑得不够充分的一个症状。

如果分支交叉交易经常变化，也许你可以把它们变成一个。

我会停止讲课 ;-) 在这一点上，希望我没有把你弄糊涂。

如果您想了解更多关于 svn 最佳实践的信息，您可能会在我的 SO-Answers 或 SVN 红皮书中找到一些内容。如果这对你来说是个问题，我可以给你发一张关于正确采摘的图表。

干杯