【发布时间】：2011-07-04 19:21:39
【问题描述】：
我已经阅读了一些关于合并一系列修订和重新集成之间区别的文档和博客，但我没有得到任何东西。
如果我选择一种或其他方式从分支合并到主干，合并有什么不同？为什么在某些情况下合并一系列修订不起作用但重新集成成功将分支合并到主干？
【问题讨论】：
-
其实是个好问题。我已经多次阅读该手册章节，但我从未真正理解它。 （就我而言，merge reintegrate 往往会失败。）
标签： svn
【发布时间】：2011-07-04 19:21:39
【问题描述】：
一方面，SVN 计算要应用的差异的方式在两种方法之间是不同的。通常，例如，当您以挑选方式将主干中的一系列修订 X 到 Y 应用到分支时，SVN 会计算主干中 X 到 Y 的修订之间的差异，并将这些差异应用于分支。你也可以在另一个方向做同样的事情，以这种方式将更改从分支应用到主干。
但是，当您将分支重新集成到主干中时，SVN 会进行不同类型的计算。 SVN 不计算分支中修订 X 到 Y 之间的差异并将这些更改应用到主干，而是仅计算整个分支和主干之间的差异。假设您一直在努力使分支与主干中所做的更改保持同步，那么主干和分支之间重新集成计算的差异将恰好是分支中尚未进行的所有更改在后备箱里。
来自the SVN 1.6 documentation（重新集成分支）：
将分支合并回 主干，但是，底层 数学完全不同。您的 功能分支现在是 重复的主干更改和 私有分支更改，所以没有 简单的连续修订范围 复制过来。通过指定
--reintegrate选项，你在问 颠覆要小心复制 仅您的分支独有的更改。 （事实上，它是通过 将最新的树干树与 最新的分支树：结果 区别正是你的分支 变化！）
我不完全确定（多年来我已经忘记了），但我认为在以前的 SVN 版本中（比如 1.5 之前的版本？），没有合并跟踪和分支重新集成选项，所以如果你想要将完成的分支合并到主干中，您必须使用修订范围方法手动完成。我正在尝试在文档中查找此内容，但尚未找到有关它的参考资料。
补充阅读
另见Re: Why is --reintegrate needed for svn 1.5 merging?，this comment 中已指出。
【讨论】：
-
希望你用数字来解释（视觉解释）。我还是不明白。
-
@Emerald214 如果有帮助，请尝试查看this comment 中的内容。
-
会把这个扔出去，以防有人用更新版本的SVN寻找这个：
--reintegrate :deprecated
reintegrate 应该在您处理功能分支时使用，并且已经完成。下一步应该是删除分支。在重新集成之前，您应该使用“修订范围”合并将目标（通常是主干）合并到分支，以将所有符合条件的修订合并到分支。这在reintegrate 段落的上方稍有描述。
“修订范围”合并用于挑选应该转到某个分支的修订，例如用于修复稳定版本分支中的错误。
【讨论】：
-
正如我所说，我在文档中阅读了这些内容。我的问题是为什么不建议将“修订范围”从分支合并回主干？
-
@SanderRijken 您应该总结该链接的内容，我认为它包含有关 为什么
--reintegrate甚至是必要的非常有用的信息，而不是一系列修订的简单合并。我认为这样做会大大改善您的答案。 -
@SanderRijken：您好先生，您能看看我的问题here吗？在此先感谢... :)
--reintegrate 应该是默认值；如果您确实有任何理由想要进行与 --reintegrat 不同的同步合并，他们可以简单地提供 --sync 来代替。 --reintegrate 是你几乎一直想要的，除非你想挑选。 （这只是我的 2 美分——我不认为自己是合并专家，我也不明白为什么他们的同步数学与他们的重新整合数学不同）——当我合并时，我几乎总是想要并且只想要在源分支，尚未合并到目标分支...
【讨论】：
-
我认为默认重新整合是非常危险的。假设您有 TRUNK 和 FEATURE_X 分支。 IIUC 如果您在将 FEATURE_X 重新集成回 TRUNK 之前忘记执行 TRUNK -> FEATURE_X 合并，或者您确实这样做了，但是在这两个步骤之间已将更改提交给 TRUNK，您只需删除在 TRUNK 上所做的更改。
-
只有在主干的所有更改完全最新的分支上才使用 --reintegrate 非常重要。正如@Cupcake 所说，应用的差异是以完全不同的方式计算的。因此，它不适用于任何其他合并操作，也不适合默认操作。