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

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. 提交a更改分支 (r6)
4. 通过以下任一方式将分支合并回主干：
   • 将修订范围 r5-r6 合并到主干 - 发生冲突，或者
   • 将 r5 合并到主干，然后将 r6 合并到主干 - 不会发生冲突

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

Answer 1

简短回答
根据我对颠覆合并行为的观察（不是书本/源知识）：

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

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

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

我尽量避免任何类型 1. 的合并。
2. 类型“常规”合并可以通过仅合并到一个方向来驯服。当你再次上下合并时，麻烦就开始了。
每当我需要像在功能分支场景中那样“交叉合并”时，我都会使用合并类型 3

。 “盲目地”合并操作:)。任何 VCS 都无法解决所有相互冲突的人类决策。

为什么 svn merge 冲突

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

1.5 SVN 之前的合并看起来像这样：（

分支的 HEAD 版本是 510）
svn merge -r500:510 http://server.tld/branches/stable-1.0

下一个合并将是：（

分支的 HEAD 修订版是 520）
svn merge -r510:520 http://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< /a>

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

如何忍受它

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

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

如果分支机构经常发生交叉交易，也许您可​​以将它们合并为一。

我将停止讲授；-) 此时，希望我没有让您感到太困惑。

如果您想了解更多有关 svn 最佳实践的信息，也许您可​​以在我的 SO-Answers 或 SVN Red book 中找到一些内容。如果这对您来说是个问题，我可以给您张贴有关正确挑选的图表。

干杯