前言
目前我们这边的内网代码是通过 TortoiseSVN 进行版本管理的，平时用着也挺好的，没碰到什么大问题。
但是，今天碰到了一个比较棘手的问题，在这里做一下记录，以方便自己和有需要的朋友在之后碰到该类问题时有个参考。
现象
具体的错误现象如下图所示：
原因
导致上述现象的步骤如下：
从最外层目录点击的更新，由于文件数量巨多，导致长时间处于检查状态；
点击了取消更新按钮；
取消响应太慢，直接从任务管理器关闭 TortoiseSVN 进程；
经过以上步骤后，再次更新就出现了该现象，不管从哪一级目录更新都是一样的错误。
尝试一
根据错误现象中的提示信息，手动执行清理操作，结果弹出下图所示的错误：
不管从哪一级目录开始，都是一样的报错，看来这条路是走不通的，只能另寻他法。
图中报错信息 Failed to run the WC DB work queue associate with xxx 的大意是：启动与 xxx 相关联的 WC DB 工作队列失败。
尝试二
通过查找资料，发现碰到这种现象的人还是蛮多的，但是，现在网上找出来的资料中，绝大部分都是建议使用 sqlite3 进行数据库清理，数据库位于时选择的那个本地目录下的 .svn 文件夹中，名称为 wc.db,如下图这样的：
.svn 里的内容当时忘了截图了，借用一下网上找到的：
吐槽一下，这个数据库文件名称 wc 让我有了不好的联想。
注意：.svn 文件夹一般是隐藏文件夹，需要设置显示。
所以，我就根据网上的教程，在外网下载了 sqlite3 的安装包，申请了导入内网。
在等待导入的过程中，我突然想到，能修改数据库文件（.db）的不仅仅只有 sqlite3，我内网机上安装的 Navicat Premium 也是能解析数据库文件的，那为什么不试一下呢？因为之前只用它连接数据库，一时没反应过来。
终解
尝试使用 Navicat Premium 打开 wc.db 文件，果然是可以正常解析的。
接下来就是按照图上标出来的步骤：
- 找到
WORK_QUEUE表； - 右键该表，选择“清空”；
- 保存
wc.db
用上面修改过的 wc.db 替换 .svn 下的 同名文件，然后再次执行清理指令。在稍等十几秒后，提示信息变为如下所示：
最后的请理结果如下：
可以看到，最终是清理 SVN 成功。
总结
通过今天这个事，我的总结如下：
- 在 SVN 更新过程中，尽量避免点击取消更新；
- 如果确实点了取消，那么就要耐心等待 SVN 执行完取消操作，不要强制关闭 SVN 进程；
- 网上的资料一般只适合用来做参考，且同质化太严重；
- 解决今天这个报错的方法肯定不止我写的这一种。
~
~ 本文完，感谢阅读！
~
学习有趣的知识，结识有趣的朋友，塑造有趣的灵魂！
