通常,当将SVN分支重新集成到主干时,我们会创建这样的历史记录:
trunk A---B---D---F---H
\ \ /
branch C---E---G---X其中G是合并,H是重新融合合并,X删除特性分支。我还了解到,SVN用于G和H的合并算法存在差异。到现在为止还好。
然而,有一件事困扰着我:This answer引用了SVN关于重新融合合并发生的情况的文档:“实际上,它是通过比较最新的主干树和最新的分支树来做到这一点的:结果的区别正是您的分支更改!”
从trunc + changes from branch = trunc + (branch - trunk) = branch开始,我得出的结论是,重新融合合并后记录的状态始终与分支末尾的记录状态完全相同。
现在考虑一下这段历史:
trunk A---B---D---F---H---I
\ \ /
branch C---E-----G-----X有了上面的推理,我假设如果I是一个重新融合合并,来自commit H的更改就会丢失。这是对的,还是我错过了什么?
发布于 2015-07-22 09:16:15
Subversion知道上一次同步修订是F,因此它计算trunk@F和branch@G之间的差异,然后将其应用于工作副本。
如果目标工作副本签出了修订F,那么重新整合将顺利进行(没有冲突),然后将wc更新为H (可能的冲突)并能够提交。
如果目标工作副本签出了修订版H,那么将在H之上执行重新整合合并(在本例中,合并期间可能发生冲突)。
无论如何,不会有任何损失。
https://stackoverflow.com/questions/31558189
复制相似问题