断电导致SVN长周期合并失败需分层修复：先备份工作副本并导出patch，再用svn cleanup或重建.wc.db；接着检查仓库db/current等文件并修复，最后根据断电时机决定重执行merge、手动commit或补提/回退。
SVN在合并长周期分支过程中遭遇断电，极易引发工作副本（Working Copy）状态错乱、.svn元数据损坏、甚至仓库（Repository）层面的文件不一致。这类问题不同于普通提交中断，因合并涉及大量路径变更、属性修改和潜在冲突标记，断电后残留的临时状态会破坏原子性保障。修复需分层处理：先稳定本地工作副本，再验证仓库完整性，必要时回退或重建。
立即停止操作并备份当前状态
断电恢复后切勿直接执行 svn update、svn commit 或再次 merge。任何写入都可能加剧损坏。应优先对整个工作目录（含 .svn 文件夹）做完整副本备份（如复制为 myproj_backup_20260612），同时导出当前未提交的修改（svn diff > pre_merge_diff.patch），为后续回溯保留线索。
清理本地工作副本残留状态
断电常导致 .svn/wc.db 锁表或事务未提交，触发 “Previous operation has not finished” 类错误：
SVN搭建及使用教学视频(布尔教育)
下载
《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。
- 进入工作副本根目录，运行 svn cleanup --include-externals，强制释放锁并重置内部状态
- 若 cleanup 失败或报 “sqlite: database disk image is malformed”，说明 wc.db 已损坏，需重建：删除 .svn 目录（保留业务代码），执行 svn checkout --force URL@HEAD . 重新检出当前版本（注意：这会丢弃未提交修改，所以此前备份和 patch 至关重要）
- 若仅部分子目录报错，可对特定路径单独 cleanup，避免全量重检
检查并修复仓库端关键文件
长周期合并若在提交瞬间断电，可能损坏仓库 db/current 或 db/revs 中最新修订版本文件：
- 登录服务器，定位仓库路径（如 /var/svn/myrepo），检查 db/current 文件内容是否为空或非数字；若为空，从 db/revs/ 下找最大编号文件夹（如 12345），将该数字写入 db/current，末尾加换行符后保存
- 检查 db/txn-current 是否存在且含有效数字；若损坏，用 db/revprops/ 下最大编号文件夹名覆盖其内容（同样需换行）
- 运行 svnadmin verify /path/to/repo 验证仓库结构完整性；若报错，说明 revs 或 revprops 中有损坏对象，需结合最近备份恢复整个 db 目录
安全完成合并或回退到已知一致点
确认本地和仓库均稳定后，决策路径取决于断电发生时机：
- 若断电发生在 merge 命令执行前（即仅更新了工作副本但未运行 merge），直接重新执行 svn merge ^/branches/feature-X 即可
- 若 merge 已部分写入但未 commit，且 svn status 显示大量 “M” 和 “C” 状态，先用备份 patch 恢复修改，再手动 resolve 冲突后 commit
- 若 commit 已发出但未完成（如客户端显示 success 而服务端无对应 revision），必须通过 svn log -l 5 确认最新 revision 号，再比对本地修改是否全部落库；缺失部分需补提，重复部分需 revert 避免重复
