svn工作副本损坏时，svn status无法执行，因wc.db是元数据唯一入口；需通过检查文件存在性、sqlite命令验证结构、svn cleanup报错等确认损坏，并借助.svn/pristine/和残留表查询辅助判断本地修改状态。
直接运行 svn status 通常无法正常执行，因为损坏的 wc.db 是 SVN 读取元数据的唯一入口。一旦数据库结构异常，命令会立即报错（如 svn: E200030: database disk image is malformed），根本不会输出任何状态信息。
确认元数据是否损坏的实用方法
先别急着修复，用这几步快速判断问题是否出在 wc.db 上：
- 进入项目根目录，检查
.svn/wc.db文件是否存在且非空（大小为 0 字节说明已损毁或被清空） - 用 SQLite 命令行工具尝试打开：
sqlite3 .svn/wc.db "SELECT count(*) FROM sqlite_master;"—— 如果返回malformed database schema或直接崩溃，基本可断定数据库结构损坏 - 执行
svn cleanup，若提示Failed to open sqlite3 db或Unable to open database，也属于典型元数据层故障
绕过 wc.db 查看文件真实修改状态
虽然 SVN 元数据不可用，但你的本地文件内容完好无损。可通过比对方式还原“被破坏的元数据”所本应记录的状态：
SVN搭建及使用教学视频(布尔教育)
下载
《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。
- 用
svn info --show-item url获取仓库 URL（只要.svn/entries或.svn/wc.db部分可用，此命令仍可能成功） - 手动比对：将当前工作目录与最新检出版本（或同事的干净副本）做文件差异对比（
diff -r或用 Beyond Compare 等工具），识别出哪些是新增、修改、删除的文件 - 查看
.svn/pristine/目录下 SHA-1 命名的原始文件，它们未被破坏，可用于校验你本地文件是否真的被改动过
提取残留元数据的关键表（需 SQLite 基础）
部分轻度损坏的 wc.db 仍可读取部分表，这对恢复提交上下文很有帮助：
-
sqlite3 .svn/wc.db "SELECT local_relpath, op_depth, presence FROM nodes LIMIT 10;"—— 查看节点基础状态（presence 字段值为 'normal'/'added'/'deleted' 可反映文件存在性） -
sqlite3 .svn/wc.db "SELECT local_relpath, repos_relpath FROM wcroot;"—— 获取工作副本根路径与仓库路径映射关系 - 若上述查询报错，说明损坏严重，建议跳过深度分析，转向备份替换或重建策略
本质上，SVN 不提供“只读模式”来绕过损坏数据库查看状态。所有可靠的状态信息都依赖 wc.db 完整可解析。因此，上述操作目的不是恢复完整元数据视图，而是帮你确认：本地文件是否安全、哪些改动真实存在、以及能否通过最小干预手段重建可用的工作副本。
