SVN迁移加载svndumpfilter过滤转储报E200003增量源错误

错误根因 #

原生svndumpfilter是无状态的流处理工具，仅做转储内容的文本匹配过滤，不会维护SVN版本库的文件节点依赖关系。该报错的触发逻辑是：r19826提交中path/to/pears.sql等文件的delta增量，在转储流中以同提交内被过滤规则排除的gigantic.sql节点作为delta计算基准，过滤操作直接删除了gigantic.sql的所有节点记录，加载转储时找不到delta源就会抛出异常，和操作系统、SVN发行版（Ubuntu原生SVN/Windows VisualSVN）无关。--drop-empty-revs、--preserve-revprops参数不涉及节点依赖修复，无法解决该类问题。

可落地修复方案 #

按操作复杂度从低到高排序：

• 方案1：补充缺失参数直接走管道处理
  调整原有管道命令，添加参数让svndumpfilter自动跳过缺失的delta源引用，同时重新编号修订版本避免空版本断层：

  svnrdump dump https://my/svn/repo/ | svndumpfilter exclude --pattern "**/gigantic.sql" --skip-missing-merge-sources --renumber-revs | svnadmin load repo
  

  注意：该方案仅适用于被过滤文件和同提交其他文件不存在内容级delta依赖的场景，部分极端情况下可能导致加载后的文件内容损坏，加载完成后必须校验r19826涉及的apples.sql、pears.sql内容是否和源仓库一致。

• 方案2：本地落地转储文件分两轮过滤
  不要直接用管道流式处理，先把完整仓库转储落地到本地文件，避免流处理时的上下文丢失，操作步骤如下：

  # 第一步：生成完整仓库转储文件
  svnrdump dump https://my/svn/repo/ > full_repo.dump
  # 第二步：第一轮过滤，排除目标大文件，跳过缺失的合并源
  svndumpfilter exclude --pattern "**/gigantic.sql" --skip-missing-merge-sources < full_repo.dump > filtered_step1.dump
  # 第三步：第二轮过滤，清理空版本、重新编号修订版本
  svndumpfilter include --pattern "**/*" --drop-empty-revs --renumber-revs < filtered_step1.dump > filtered_final.dump
  # 第四步：创建新仓库加载最终转储文件
  svnadmin create repo && svnadmin load repo < filtered_final.dump
  

  该方案修复成功率远高于直接管道处理，适合大多数普通仓库场景。

• 方案3：使用支持依赖解析的历史编辑工具重建版本链
  如果前两种方案仍然报错，说明被过滤的gigantic.sql和其他文件存在跨版本的delta依赖，原生svndumpfilter无法处理这类场景：

  1. 先对源SVN仓库做本地热拷贝，所有操作在本地副本上执行，避免影响线上仓库
  2. 通过支持节点依赖解析的SVN历史编辑工具，删除所有历史版本中的gigantic.sql节点，工具会自动重建所有受影响文件的delta链，不需要手动处理版本引用
  3. 从修复后的本地仓库重新生成dump文件，再导入GitHub即可
     该方案可以100%规避delta源缺失问题，适合提交关系复杂、文件delta依赖多的大型仓库。

迁移后校验项 #

所有操作完成后，必须抽查以下内容确认迁移结果正确：

• r19826提交涉及的所有文件（apples.sql、pears.sql）内容和源仓库一致
• 全仓库所有分支、标签的历史中不存在任何路径下的gigantic.sql文件
• 提交记录完整，没有出现文件内容截断、提交元数据丢失的问题

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