svn更新断网导致“working copy locked”错误，本质是.wc.db中事务记录未完成；应优先执行svn cleanup --include-externals，失败则用--force或tortoisesvn勾选“break locks”，仍无效时清空work_queue表，最后排查权限、占用及忽略规则，极端情况再重建副本。
SVN更新中途断网，最典型的表现是后续所有命令（svn status、svn update、svn commit）都报错，提示 “Working copy locked” 或 “corrupted working copy”。这不是文件损坏，而是元数据状态不一致——.svn/wc.db 里残留了未完成的事务记录，客户端为保护一致性主动拒绝操作。解决核心是恢复元数据与文件系统的同步，而不是盲目删.svn。
先用标准 cleanup 恢复（多数情况一步到位）
这是第一反应动作，也是最安全的起点：
- 进入工作副本根目录，运行
svn cleanup --include-externals（加--include-externals可一并清理外部引用） - 若提示“locked”且 cleanup 失败，改用强制清理：
svn cleanup --force - Windows 下用 TortoiseSVN 时，右键 → Cleanup → 勾选 “Break locks”（关键！不勾选就解不了锁）
清理失败？直接干预 wc.db 数据库
当 cleanup 报错或反复无效，说明 .svn/wc.db 中的 WORK_QUEUE 表卡住了未完成任务：
- 用 DB Browser for SQLite 打开
.svn/wc.db - 找到
WORK_QUEUE表，清空其全部内容（不是删表，只是DELETE FROM WORK_QUEUE） - 保存并关闭数据库，再运行一次
svn cleanup，通常就能继续更新
检查干扰因素：权限、占用、忽略规则
有些“锁”其实是假象，由外部环境引起：
- 确认 IDE、编辑器、杀毒软件没在独占项目文件（尤其
.svn/下的文件） - 检查当前用户对整个工作副本有完整读写权限（Linux/macOS 注意 umask；Windows 注意属性“只读”是否被误勾）
- 运行
svn pg svn:ignore .查看当前目录是否被意外设为忽略；如有，用svn propdel svn:ignore .删除
实在不行再考虑重建副本
仅当上述全无效，且你确认没有未提交的重要修改时才采用：
- 先把当前代码整体复制备份（含未提交变更）
- 删除原工作副本（保留备份）
- 重新
svn checkout到新目录 - 把备份里的修改手工合并过去（注意别覆盖
.svn）
不复杂但容易忽略
