Question

通常，当将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是重新整合合并，那么来自提交H的更改就会丢失。这是正确的，还是我错过了什么？

Answer 1

Subversion知道上次同步修订版本为F，因此它会计算trunk@F和branch@G之间的差异，然后将其应用于工作副本。

如果目标工作副本签出了修订版F，那么重新整合将顺利进行（没有冲突），然后将wc更新为H（可能的冲突）并能够提交。

如果目标工作副本签出了修订版H，则会在H之上执行重新整合合并（在这种情况下，合并期间可能会发生冲突）

无论如何都不会丢失任何东西。