如果在最后一次合并和 SVN 中的重新集成合并之间有一个提交，会发生什么情况？
What happens if there is a commit between the last merge and the reintegration merge in SVN?
一般情况下，在将一个SVN分支重新整合到主干中时，我们会创建一个这样的历史：
trunk A---B---D---F---H
\ \ /
branch C---E---G---X
其中G为合并，H为重新整合合并，X删除特性分支。我还了解到 SVN 用于 G 和 H 的合并算法存在差异。到目前为止，还不错。
但是，有一件事困扰着我：This answer 引用 SVN 文档关于重新整合合并会发生什么："And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!"
从trunc + changes from branch = trunc + (branch - trunk) = branch开始，我得出结论，重新合并合并后的记录状态始终与分支结束时的记录状态完全相同。
现在想想这段历史：
trunk A---B---D---F---H---I
\ \ /
branch C---E-----G-----X
根据上面的推理，如果 I 是重新集成合并，我假设来自提交 H 的更改只是丢失。这是正确的，还是我遗漏了什么？
Subversion 知道最后一个同步版本是 F，所以它计算 trunk@F 和 branch@G 之间的差异，然后将其应用到工作副本。
如果目标工作副本签出了修订版 F，那么重新集成将顺利进行（没有冲突），之后您将 wc 更新为 H（可能存在冲突）并能够提交。
如果目标工作副本签出修订 H，则将在 H 之上执行重新集成合并（在这种情况下，合并期间可能会发生冲突）
无论如何都不会丢失任何东西。
一般情况下，在将一个SVN分支重新整合到主干中时，我们会创建一个这样的历史：
trunk A---B---D---F---H
\ \ /
branch C---E---G---X
其中G为合并，H为重新整合合并，X删除特性分支。我还了解到 SVN 用于 G 和 H 的合并算法存在差异。到目前为止，还不错。
但是，有一件事困扰着我：This answer 引用 SVN 文档关于重新整合合并会发生什么："And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!"
从trunc + changes from branch = trunc + (branch - trunk) = branch开始，我得出结论，重新合并合并后的记录状态始终与分支结束时的记录状态完全相同。
现在想想这段历史：
trunk A---B---D---F---H---I
\ \ /
branch C---E-----G-----X
根据上面的推理，如果 I 是重新集成合并，我假设来自提交 H 的更改只是丢失。这是正确的，还是我遗漏了什么？
Subversion 知道最后一个同步版本是 F，所以它计算 trunk@F 和 branch@G 之间的差异，然后将其应用到工作副本。
如果目标工作副本签出了修订版 F，那么重新集成将顺利进行（没有冲突），之后您将 wc 更新为 H（可能存在冲突）并能够提交。
如果目标工作副本签出修订 H，则将在 H 之上执行重新集成合并（在这种情况下，合并期间可能会发生冲突）
无论如何都不会丢失任何东西。