关于TortoiseSVN合并树与范围合并的疑问求证

为什么范围合并是团队协作的标准实践？ #

• 避免重复合并与冲突冗余：
  合并树本质是对源树和目标树的当前状态做全量对比合并，但SVN的mergeinfo（合并追踪元数据）是基于修订范围来记录已合并内容的。如果用合并树更新分支，SVN无法精准标记哪些修订已经被合并过，后续再同步主干变更时，极可能重复引入已合并的修订，引发不必要的冲突，甚至出现代码重复应用或回滚的问题。
  举个实际场景：分支创建后，主干有r100、r105、r110三次代码变更，用合并树合并一次后，mergeinfo不会记录这三个具体修订范围。当主干更新到r120时，再次用合并树同步，系统会重新对比全量代码，把r100-r110的变更再处理一遍——哪怕这些内容已经在分支里存在了。

• 支持精细化变更控制：
  团队协作中，主干往往同时推进多个特性或修复，并非所有主干变更都需要同步到分支（比如某个特性尚未稳定，或者分支是旧版本维护分支，不需要新功能）。范围合并可以精准选择从上次合并到当前的主干修订范围，只合并需要的变更；而合并树只能全量同步主干的当前状态，完全没有筛选空间。

• 契合SVN合并追踪的设计逻辑：
  SVN的mergeinfo是维护合并历史、避免重复合并的核心机制，范围合并会自动更新mergeinfo，记录本次合并的精确修订范围，后续合并时SVN会自动跳过已处理过的修订。但合并树不会正确更新mergeinfo，会直接破坏SVN的合并追踪链，长期下来分支的合并历史会变得混乱不堪，难以排查问题。

你测试中合并树“没问题”的局限 #

你测试的场景大概率比较简单：主干变更线性无重叠，且仅做了单次合并。在这种理想化的场景下，合并树确实能得到正确结果，但一旦涉及多次合并、复杂变更（比如同一文件被多次修改、分支有本地自定义变更），合并树的缺陷就会立刻暴露——比如重复合并导致的代码冲突、mergeinfo混乱引发的合并错误。

正确的分支更新流程（范围合并） #

1. 确保分支工作副本是最新版本，执行svn update。
2. 查看分支的mergeinfo（通过svn propget svn:mergeinfo命令），找到上次合并主干时的终止修订号。
3. 执行范围合并：选择从“上次合并的终止修订号”到“主干最新修订号”的范围，合并到分支工作副本。
4. 解决冲突、完成测试后提交合并结果，此时SVN会自动更新mergeinfo，记录本次合并的修订范围。

关于官方文档的困惑解析 #

官方文档提到的“指定起始版本”，指的是上次合并主干到分支时的主干终止版本，而非分支创建版本或主干最新版本。如果你的测试中指定了错误的起始版本，自然会导致合并失效。正确的起始版本是确保SVN能准确识别需要合并的新变更的关键。

内容的提问来源于stack exchange，提问作者Lugh