Subversion报svn_relpath_join断言失败 版本库修复方案咨询

该故障确定由版本库修订版本损坏引发，核心依据如下：

• 执行svnadmin verify官方完整性校验时，流程在走完4343号修订版本后触发断言崩溃，报错指向路径拼接逻辑检测到不符合规范的相对路径，说明4344号修订版本的内部存储结构已经损坏，无法被SVN核心库正常解析。
• TortoiseSVN弹出的「Could not convert '### error ###' into a number」是上层客户端的连锁报错：客户端拉取分支目录结构、提交日志时需要逐段解析修订版本的元数据，碰到损坏的4344版本时拿到了非法的错误占位符，无法转换成预期的数字类型字段（版本号、时间戳、条目计数等），直接抛出异常阻断操作。
  从你贴的/path/to/repository/db/revs/4/目录列表看，文件权限、大小无明显异常，损坏不是权限配置错误导致，大概率是磁盘坏道、提交写入时服务异常中断、存储介质静默错误引发的单版本文件内部损坏。

所有操作前先停掉SVN对应的访问服务（Apache、svnserve等），先对整个版本库目录做全量冷备份到其他存储介质，所有修复操作都在备份副本上执行，避免二次损坏原始数据。按操作复杂度从低到高依次尝试：

• 方案1：使用SVN自带修复工具重建索引
  执行官方修复命令，重建版本库索引、重置残留文件锁，可解决大部分轻度元数据损坏问题：

  svnadmin recover /path/to/your/repository/copy
  

  命令执行完成后重新跑svnadmin verify，确认校验是否能顺利通过4344版本。
• 方案2：导出完好修订版本重建新库
  如果recover操作后校验仍然失败，可以剥离损坏版本，用确认完好的0-4343版本重建可用版本库：
  1. 创建全新空版本库：

     svnadmin create /path/to/new/healthy/repository
     

  2. 从旧库导出0到4343的所有完好修订版本：

     svnadmin dump /path/to/old/repository -r 0:4343 > valid_svn_revs.dump
     

  3. 将导出的完好数据导入新库：

     svnadmin load /path/to/new/healthy/repository < valid_svn_revs.dump
     

  4. 对新库执行全量verify校验确认无问题后，替换旧版本库路径，重新配置访问权限即可恢复服务。

  该方案会丢失4344到4360共计17个修订版本的提交内容，如果这些提交的代码、文件在开发人员本地工作副本有留存，可以在新库上线后重新提交补全。

• 方案3：低级别修复标记损坏节点保留后续版本
  如果不想丢失4344之后的提交内容，使用SVN 1.9及以上版本自带的svnfsfs工具做低级别修复：
  1. 执行扫描命令自动标记损坏节点：

     svnfsfs verify /path/to/repository/copy --mark-corrupt
     

  2. 扫描完成后重新执行校验，工具会自动跳过损坏节点，允许后续完好的修订版本被正常读取。修复完成后用TortoiseSVN测试分支访问、日志查看功能是否恢复正常。

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