如果在SVN中的最后一次合并和重新整合合并之间存在提交，会发生什么情况?

Question

通常，当将SVN分支重新集成到主干中时，我们会创建这样的历史记录:

trunk   A---B---D---F---H
                     /
branch        C---E---G---X

，其中G为合并，H为重新整合合并，X为删除特征分支。我还发现SVN对G和H使用的合并算法存在差异。到目前为止，一切顺利。

然而，有一件事让我很困扰:这个答案引用了SVN关于重新整合合并的文档:"事实上，它通过比较最新的主干树和最新的分支树来实现这一点:结果的差异正是你的分支更改!"

从trunc + changes from branch = trunc + (branch - trunk) = branch开始，我得出结论，重新整合合并后记录的状态总是与分支结束时记录的状态完全相同。

现在考虑这段历史:

trunk   A---B---D---F---H---I
                        /
branch        C---E-----G-----X

根据上面的推理，我假设如果I是一个重新整合合并，那么提交H的更改就会丢失。这是对的吗，还是我漏掉了什么?

Answer 1

Subversion知道最后一个同步版本是F，所以它计算trunk@F和branch@G之间的差异，然后应用到工作副本。

如果目标工作副本签出版本F，那么重新集成将顺利进行(没有冲突)，之后您将wc更新到H(可能存在冲突)并能够提交。

如果目标工作副本签出版本H，那么重新整合合并将在H之上执行(在这种情况下合并期间可能发生冲突)

无论如何也不会有什么损失。