TortoiseSVN 能否跨不同版本库进行合并？答案非常明确：不能。这是其底层设计中的一项硬性限制——它仅认可同一 SVN 仓库（repository）内部的“血缘关系”。所谓不同版本库，指的是 URL 完全独立、彼此之间没有版本关联的两个地址，例如 svn://server/repo-a 与 svn://server/repo-b。这两个仓库之间不存在共享的提交历史，SVN 无法判断哪个路径是哪个的分支，更无法找到合并的公共基点。最终结果：合并向导直接拒绝操作，命令行也同样会返回“no common ancestry”的错误信息。
为何无法跨版本库合并？
SVN 的合并机制本质上依赖于版本树的血缘关系。打个比方，就像家族中分支必须是从某个共同祖先“廉价复制”而来——比如从 trunk 的某次提交创建出一条新分支。合并时 SVN 需要计算两条路径之间的差异（即变更集），这依赖一条能够追溯到共同父版本的线索。不同仓库的版本号彼此孤立，元数据也各自独立，SVN 根本不知道哪些改动该应用、哪些该忽略。因此，强行填入两个不同仓库的 URL 执行“Merge two different trees”操作，大概率要么直接失败，要么产生不可预料的混乱覆盖。
替代方案：手动同步与版本标记
如果确实需要将 repo-B 中的某段代码迁移到 repo-A，就不要指望“合并”按钮了，建议走受控的手动流程。推荐以下三种方式：
- 导出 + 导入：在 repo-B 中右键目标文件夹 → “Export”，将其保存为本地干净副本；然后在 repo-A 的工作副本中新建目录或文件，粘贴内容后提交。如果想要保留原作者的提交信息，请自行手动注明。
- 补丁迁移：在 repo-B 中选中要迁移的提交 → 右键 “Show log” → 选中对应 revision → “Save as patch…”。然后回到 repo-A 的工作副本，右键 → “Apply patch…”。这种方法适用于改动范围小、目录结构一致的情况，干净利落。
- 外部引用（externals）：如果两个仓库长期存在关联（例如共用工具库、配置模块），可以在 repo-A 的 trunk 中定义
svn:externals属性，指向 repo-B 的某个固定标签路径。这样不复制代码，而是动态引用，既省心又省力。
特别注意：别被“URL 相似”误导
下面这些情况实际上属于同一仓库，可以正常合并：
svn://host/project/trunk和svn://host/project/branches/feat-xhttps://svn.example.com/repos/app/trunk和https://svn.example.com/repos/app/tags/v2.1
只要域名、端口、路径前缀完全一致，后面只是子目录的差异，那它们就属于同一个 repository。TortoiseSVN 能自动识别祖先关系，合并操作可以放心使用。
真正跨版本库时，没有捷径可走。硬填两个不同仓库的 URL？结果只有两个：失败，或者一团乱麻般的覆盖。所以，不要偷懒，手动同步才是正道。
