前言
目前我们这边的内网代码是通过 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 进程;
- 网上的资料一般只适合用来做参考,且同质化太严重;
- 解决今天这个报错的方法肯定不止我写的这一种。
~ 本文完,感谢阅读!