如何解决SVN服务端由于版本太旧不支持合并追踪的报错

先说结论：直接升级服务端版本是唯一可靠的解法。SVN 1.4.x 这类老版本根本不支持 mergeinfo 元数据和自动合并追踪——这项功能从 1.6 版本才正式引入并稳定实现，客户端再新也没用，因为 mergeinfo 的读写始终由服务端控制。

确认当前服务端与客户端版本

动手之前，先得把问题根源摸清楚，避免白忙一场：

• 查服务端版本：登录服务器，运行 svnserve --version（svnserve 模式）或 svnadmin --version（通常与服务端版本一致）；如果用的是 Apache 部署，则需要检查 mod_da v_svn 模块对应的 Subversion 版本。
• 查客户端版本：TortoiseSVN 右键 →“关于”，Eclipse 中查看插件属性，或者命令行执行 svn --version。
• 特别注意：即便客户端已经是 1.14.x，只要服务端还是 1.4.6，所有 merge 操作都会被拒绝，报错信息类似 retrieval of mergeinfo unsupported by … 或 Working Copy and repository filesystem format mismatch。

升级 SVN 服务端（不可跳过）

降级客户端或者手动合并都只是临时绕行，代价是彻底丢失合并历史追踪能力，长期来看必然引发混乱。正确做法分这几步：

• 完整备份仓库：执行 svnadmin dump /path/to/repo > repo_backup.dump（推荐全量导出，最稳妥）。
• 安装新版 Subversion：建议选择 ≥1.6.23 或 ≥1.8.x，避开那些已知有安全缺陷的中间小版本。
• 升级仓库格式：运行 svnadmin upgrade /path/to/repo——这个命令只更新元数据结构，不会改动任何提交内容。
• 验证效果：重启 svnserve 或 Apache，用客户端重新 checkout 一个新工作副本，执行 svn info 查看是否正常显示 Revision 和 Repository UUID，并且不再报 mergeinfo 相关错误。

同步校准客户端与工作副本

服务端升级后，本地环境也得跟上，否则还是会因格式不兼容而失败：

• 统一客户端大版本：确保 TortoiseSVN、Eclipse 插件、命令行 svn 使用同一个大版本（比如全部固定在 1.10.x），避免混用导致 .svn 目录结构冲突。
• 清理旧工作副本：从 1.4 时代检出的老工作副本大概率没法直接复用。建议删除本地目录，重新 checkout；如果必须保留未提交的修改，先用 svn export 备份变更，然后在 clean checkout 后手工应用。
• 禁用老旧插件：Eclipse 中卸载 Subclipse 1.6 以下的版本，改用 Subversive + 匹配的 Connector，或者直接使用官方推荐的 Subclipse 4.x。

合并前的关键检查项

版本都对齐了，合并操作仍可能翻车，提前排除几个常见干扰因素很有必要：

• 确保待合并路径下没有未提交的本地修改，也没有处于 conflicted 状态的文件。
• 检查目标分支是否完整存在：如果主干（trunk）中曾经删除了某个文件或目录，而该路径又出现在分支里，就会触发 Merge tracking not allowed with missing subtrees 错误。这时需要先在主干中恢复该路径（或者明确删除后提交），再尝试合并。
• 避免混合修订版工作副本：先用 svn update 统一更新到最新版本，再执行 merge，否则会报 Cannot merge into mixed-revision working copy。