Svn 为什么合并一系列修订不同于单独合并修订？

我一直在尝试了解SVN合并/重新整合，并阅读了以下文章/书籍：

我显然还没有完全理解，因为我不明白为什么在合并回主干（反射/循环合并）中包含同步修订是一个问题——我确实看到了不排除修订的理由

如果主干上的一行文件a合并到分支上的文件a，然后再合并回主干，那么a和a之间肯定没有区别，所以没有冲突？为什么“[合并]回主干中已经存在的更改”是一个问题

我试图复制冲突场景，试图了解重新融入对我的影响，但更让我困惑的是这种场景：

在主干上提交更改（r4）

将r4合并到分支并提交（r5）

在分支上提交更改（r6）

通过以下任一方式将分支合并回主干：

• 正在将修订范围r5-r6合并到主干-发生冲突，或
• 将r5合并到主干，然后将r6合并到主干-不会发生冲突

---

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

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

带有显式修订的合并似乎完全不知道以前的合并，并且会在执行合并时重新应用更改

没有任何修订范围的“常规”合并会知道哪些修订已合并（到该目标分支）。通常不会应用两次更改。但是，它不会检查要合并的更改是否起源于现在是合并目标的同一分支。当这种情况发生时，它会有某种上下文敏感的合并，但冲突往往会在无意识的情况下发生

合并——重新整合能够检测到源于合并目标过去的更改，并且不会重新应用这些更改。不幸的是，重新整合仅适用于功能分支

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

SVN根本无法“盲目地”支持广泛的合并操作：。没有一家风险投资公司能够解决所有相互冲突的人为决策

为什么svn合并冲突

其特殊“冲突性”的部分原因可以在颠覆历史中找到。在SVN1.5之前，只有显式合并。您必须知道allready合并的修订范围，并基于该知识进行下一次合并，否则将发生您描述的冲突

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

（分行总分修订为510） svn合并-r500:510

下一次合并将是：

（分行总分修订为520） svn合并-r510:520

此语法仍然有效且有效

您可以阅读我在svn 1.4最佳实践中描述的内容：（注意，传统链接！）

随着SVN1.5中引入的合并功能，它开始评估您的一些意图。 例如，现在SVN将进行定义范围的数学运算，以便自动合并，并跟踪在何处合并的内容。减少开销，减少因人为错误引起的冲突。 但是当使用多个分支时，您可能仍然需要应用两次更改。颠覆保留了这种能力

如何适应它

你在4步示例中所做的樱桃采摘可以让你的树干和树枝非常“紧”。在步骤3中，您的两个分支是相同的。步骤4中的合并不再有任何意义。 我知道你简化了，在现实世界中会有更多的变化。但颠覆分支的主要思想是分离。来自不稳定、不兼容的开发、自定义版本的稳定

频繁挑选/交叉合并的需要通常只是没有充分考虑分支和分支使用策略的症状

如果分支机构经常进行交叉交易，也许你可以让它们成为一个

我会停止演讲；-）在这一点上，希望我没有把你弄糊涂

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

---

干杯

嗨，克里斯托夫，非常感谢您的详细回复。我已经放弃了期待答案，所以有一段时间没有回来查看！当我的大脑稍微活跃一点时，我会通读并消化它，然后做出反应。再次感谢。