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

Question

我一直试图了解SVN合并/重新整合并阅读这些文章/书籍:

我显然还没有得到它,因为我不明白为什么在合并回到主干(反射/循环合并)中包含同步修订是一个问题 - 我确实看到了不排除修订的理由.

如果主干上的文件A行合并到分支上的文件A'然后合并回主干,那么A和A'之间肯定没有区别,所以没有冲突？为什么"[合并] 返回已经存在于主干中的变化 "这个问题？

我正在尝试复制冲突场景,试图理解重新整合对我的影响,但更令我困惑的是这种情况:

在trunk上提交更改(r4)
将r4合并到分支并提交(r5)
在分支上提交更改(r6)
通过以下任一方法将分支合并到主干:
- 将修订版本范围r5-r6合并到主干 - 发生冲突,或
- 将r5合并到trunk,然后将r6合并到trunk - 不会发生冲突

我正在使用SmartSVN 6.6和SVN 1.6.合并修订范围与单独合并每个修订版时,为什么会有不同的结果？最终,为什么反思合并是一个问题？

Answer 1

基于我对颠覆合并行为的观察(不是书籍/来源知识)的简短回答:

具有显式修订的合并似乎完全不知道先前的合并,并且会像合并一样经常重新应用更改.
没有任何修订范围的"常规"合并会知道已经整合了哪些修订(到目标分支).通常情况下,更改不会应用两次.但是,它不检查要合并的更改是否源自现在是合并目标的同一分支.当发生这种情况时,它会有某种上下文敏感的合并,但是冲突会更频繁地出现.
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.5中引入的合并功能,它开始衡量您的一些意图.例如,现在SVN将自动定义要合并的范围,并跟踪合并的位置.由于人为错误,开销减少,冲突减少.但是当使用许多分支时,您仍然可能希望两次应用更改.Subversion保留了这种能力.

如何与它共存

你在4个步骤中做的樱桃采摘使你的树干和树枝非常"紧".在步骤3,你的两个分支是相同的hense合并在步骤4中没有任何意义.我知道你简化了,在现实世界的情况下会有更多变化.但颠覆分支的主要思想是分开.从不稳定,不兼容的开发,自定义构建稳定...

对挑选/交叉合并的需求通常只是通过分支和分支使用策略不够好的一个症状.

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

我会停止讲课;-)此时,希望我没有太多混淆你.

如果你想了解更多关于svn最佳实践的知识,你可以在我的SO-Answers或SVN Red书中找到一些.如果这对你来说是一个问题,我可以给你发一个关于正确的樱桃挑选的图表.

干杯

为什么合并一系列修订版本与单独合并它们有​​何不同？