我一直试图了解SVN合并/重新整合并阅读这些文章/书籍：
http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
我显然还没有得到它，因为我无法理解为什么包含在合并回到主干（反射/循环合并）中的同步修订是一个问题 - 我确实看到了理由因为不包括修订版。
如果主干上的文件A行合并到分支上的文件A'然后合并回主干，那么A和A'之间肯定没有区别，所以没有冲突？为什么“[合并] 返回已经存在于主干中的更改”这个问题？
我正在尝试复制冲突场景，试着去欣赏重新整合对我的影响，但更令我困惑的是这种情况：
我正在使用SmartSVN 6.6和SVN 1.6。合并修订范围与单独合并每个修订版时，为什么会有不同的结果？最终，为什么反思合并是一个问题？
答案 0 :(得分：5)
简短回答 基于我对颠覆合并行为的观察（不是书籍/来源知识）：
与显式修订合并似乎完全没有意识到之前的合并，并且会像合并一样经常重新应用更改。
没有任何修订范围的“常规”合并会知道哪些修订已经全部合并（到目标分支）。通常情况下，更改不会应用两次。但是，它不检查要合并的更改是否源自现在是合并目标的同一分支。当发生这种情况时，它会有某种上下文敏感的合并，但是冲突会更频繁地出现。
merge --reintegrate能够检测源自合并目标的过去的更改，并且不会重新应用这些更改。不幸的是，重新整合只适用于功能分支。
我尽量避免任何类型1的合并。 2.类型“常规”合并只能通过合并到一个方向来驯服。当您再次合并上下时，麻烦就开始了。 每当我需要像在特征分支场景中那样“交叉合并”时，我使用合并类型3.或者使用修订版本进行cherrypicking（显式修订范围与--record-only合并）
SVN根本无法支持广泛的合并操作“盲目”:)。没有VCS可以解决所有冲突的人类决策。
为什么svn合并冲突
其特定的“冲突”的原因部分可以在颠覆历史中找到。 Pre 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
借助SVN 1.5中引入的合并功能，它开始衡量您的一些意图。 例如，现在SVN将自动定义要合并的范围，并跟踪合并的位置。由于人为错误，开销减少，冲突减少。 但是，当使用许多分支时，您仍可能希望应用更改两次。 Subversion保留了这种能力。
如何与之共存
在您的4步示例中进行的樱桃采摘使您的树干和树枝非常“紧”。在第3步，你的两个分支是相同的hense合并在第4步中没有任何意义。 我知道你简化了，在现实世界的情况下会有更多变化。但颠覆分支的主要思想是分开。从不稳定，不兼容的开发，自定义构建稳定...
对挑选/交叉合并的需求通常只是通过分支和分支使用政策考虑不足的一个症状。
如果分支机构经常进行交叉交易，也许你可以将它们变成一个。
我会停止讲课;-)此时希望我没有太多地混淆你。
如果你想了解更多关于svn最佳实践的知识，你可以在我的SO-Answers或SVN Red book中找到一些。如果这对你来说是一个问题，我可以给你发一张关于正确的樱桃挑选的图表。
欢呼声