svn报“无法读取格式文件”或“版本库损坏”分本地wc.db损坏（e200030）和服务端仓库异常（e160004等）两类；需先通过报错范围、svn info/status结果区分源头，再分别采用替换wc.db、sqlite3修复或svnadmin recover等对应方案。
遇到SVN提示“无法读取格式文件”或“版本库损坏”，通常指向两种不同层级的问题：一种是**本地工作副本（Working Copy）的 wc.db 损坏**，表现为 svn: E200030: database disk image is malformed；另一种是**远程仓库（Repository）本身异常**，比如 svn: E160004: Unrecognized URL scheme、Can't open file 'db/current': Permission denied 或服务启动失败等。二者修复路径完全不同，需先区分清楚。
确认是本地损坏还是服务端损坏
先快速判断问题源头：
- 如果只有你一人报错，其他人能正常 update/commit → 大概率是你的 .svn/wc.db 文件损坏（本地问题）
- 如果多人同时无法访问、服务进程崩溃、Apache/mod_dav_svn 报 500 错误、或 svnserve 启动失败 → 问题在 服务器端仓库（Repository）
- 执行
svn info能显示 URL 和当前版本 → 说明本地元数据基本可用，问题更可能出在服务端或网络 - 执行
svn status直接报错且提示“database disk image is malformed” → 明确是本地 wc.db 损坏
本地工作副本损坏：优先尝试安全替换法
这是最快、最稳妥的恢复方式，不丢失任何未提交修改。
SVN搭建及使用教学视频(布尔教育)
下载
《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。
- 进入项目根目录，备份整个
.svn文件夹（尤其.svn/wc.db）到桌面或其他安全位置 - 找一位同事，确认其工作副本与你同分支、同URL、已执行
svn update到最新干净状态 - 复制他
.svn/wc.db文件，覆盖你本地的同名文件 - 运行
svn status验证：应能正确列出你的修改；再试svn update或svn commit - 若仍报错，说明损坏较深，可尝试 SQLite 命令修复（见下一条）
本地 wc.db 深度损坏：用 sqlite3 工具修复
当替换法无效时，可手动检查并重建数据库结构。
- 安装 sqlite3 命令行工具（Windows 可下载预编译版，macOS/Linux 一般自带）
- 执行
sqlite3 .svn/wc.db ".dump" | sqlite3 .svn/wc.db.repaired—— 尝试导出再重建 - 若报错 “malformed database”, 改用
sqlite3 .svn/wc.db ".recover" | sqlite3 .svn/wc.db.fixed（SQLite 3.20+ 支持） - 成功后，将
.svn/wc.db.fixed重命名为wc.db，替换原文件 - 最后运行
svn cleanup清理残留锁，并svn status确认状态
服务端仓库损坏：用 svnadmin recover 恢复
适用于 svnserve 或 Apache 托管的仓库因断电、崩溃导致事务中断、锁未释放等情况。
- 登录 SVN 服务器，切换到仓库根目录（如
/var/svn/myrepo） - 执行
svnadmin recover /path/to/repository—— 自动解锁、清理未完成事务 - 检查权限：
ls -la db/确保current、revs/、revprops/可读写，属主为 svn 进程用户 - 若
db/current内容与revs/下最大版本号不一致（如 current 是 1722，但 revs 下有 1723），可手动修正 current 文件内容为实际最新版本号 - 重启 svnserve 或 Apache 服务，再从客户端测试连接
