遇到“工作副本已被破坏”提示，本质是.svn/wc.db损坏但源码完好，应先完整备份项目及wc.db文件，再优先用同事正常wc.db替换，或通过sqlite3诊断修复。
遇到“工作副本已被破坏，请重新检出”这类提示，本质是 .svn/wc.db 这个 SQLite 数据库文件损坏了，但你的源码文件通常完好无损。直接重检出会丢失所有未提交修改，其实没必要——只要操作得当，90% 的情况都能救回来。
立即备份，保住代码命脉
这是所有后续操作的前提，一步都不能跳过：
- 把整个项目文件夹（含所有你改过的代码）复制到另一个位置，比如
myproject_backup_20260617 - 单独找到项目根目录下的
.svn/wc.db，复制一份并重命名为wc.db.bak - 如果项目有 externals（外部引用），也一并备份对应子目录里的
.svn/wc.db
优先试试“换账本”法（最快最稳）
如果你的同事刚更新过同一分支且状态正常，他的 wc.db 就是现成的救命稻草：
- 请同事确认：已执行
svn update、无未提交修改、检出路径和仓库 URL 完全一致 - 让他把
.svn/wc.db发给你，替换你本地损坏的同名文件 - 运行
svn status—— 若看到M（修改）、A（新增）等标记，说明成功恢复
用 SQLite 工具诊断并修复
当没有健康副本可用时，可尝试直接修复数据库：
- 打开终端，进入项目根目录，执行：
sqlite3 .svn/wc.db "PRAGMA integrity_check;" - 若返回
ok，说明结构尚可，问题可能在个别表；若报错，则需重建 - 导出关键表（如 NODES）：
sqlite3 .svn/wc.db ".dump NODES" > nodes.sql - 新建空库导入：
sqlite3 wc.db.new
手动嫁接保留全部修改（终极保底）
当数据库完全无法读取时，用“人工方式”迁移你的改动：
- 执行
svn checkout https://your-repo-url/trunk myproject_fresh拉一个干净副本 - 把你原项目里所有非
.svn的文件和文件夹，全部复制覆盖到新副本中 - 进入新副本目录，运行
svn status，你会看到所有修改都被识别为M - 注意跳过
.svn目录，避免混入旧元数据
