svn自带命令无法修复损坏的.svn/wc.db数据库，需借助sqlite3清空work_queue和wc_lock表或替换健康wc.db文件，严重时需强制重检出并手动恢复文件状态。
直接用 SVN 自带命令无法修复损坏的 .svn/wc.db 数据库。当出现 database disk image is malformed 或 failed to run the wc db 这类错误时，说明 SQLite 元数据库已结构性损坏，SVN 命令行（如 svn cleanup、svn update）会直接失败，必须借助外部工具干预。
先确认损坏类型和范围
不是所有“工作副本异常”都需动数据库。先执行基础诊断：
- 运行
svn status：若能列出修改但后续命令报错，大概率是wc.db损坏；若直接崩溃或提示“no working copy”，可能是.svn目录整体缺失或权限问题 - 检查
.svn/wc.db文件大小：正常值通常在几百 KB 到几 MB；若为 0 字节、明显偏小（如仅几十字节），或 Windows 提示“文件已损坏”，基本可判定数据库文件异常 - 尝试
svn cleanup --include-externals：对轻度锁残留有效，但对 SQLite 结构损坏无效
核心修复：用 sqlite3.exe 清空异常队列与锁表
这是最常用、成功率最高的手动修复方式，适用于进程中断导致的事务未提交类损坏。
- 下载官方
sqlite3.exe（从 sqlite.org/download.html 获取 Windows 预编译版，解压后取其中的sqlite3.exe） - 打开命令提示符，进入你的工作副本根目录（如
D:\project），再进入.svn子目录：cd .svn - 执行
sqlite3 wc.db进入交互模式，依次输入以下命令：
DELETE FROM WORK_QUEUE;
DELETE FROM WC_LOCK;
COMMIT;
.quit
SVN搭建及使用教学视频(布尔教育)
下载
《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。
完成后回到项目根目录，运行 svn cleanup —— 此时应不再报错，后续 svn update 或 svn status 即可恢复使用。
备用方案：用健康副本替换 wc.db
适合团队协作环境，前提是同事的工作副本与你路径、URL、版本号一致且状态干净。
- 请同事在其工作副本的
.svn目录下复制wc.db文件 - 你先将自己损坏的
.svn/wc.db重命名为wc.db.bak备份 - 把同事的
wc.db粘贴到你的.svn目录下，覆盖原文件 - 执行
svn cleanup，再运行svn status确认本地修改是否仍被识别
严重损坏时重建元数据（保留文件内容）
当 wc.db 无法被 sqlite3 打开，或 NODES 表等核心结构损坏时，需放弃数据库，只保留物理文件：
- 备份整个项目文件夹（确保所有未提交代码都在）
- 删除当前工作副本中的
.svn目录（注意：只删.svn，不删源码） - 执行
svn checkout --force .（在当前目录强制检出，SVN 会复用已有文件，仅更新元数据） - 运行
svn status查看哪些文件显示为?（未受控），对它们执行svn add；对已修改但未标记的文件，用svn revert+svn add或手动比对恢复
