svn执行commit命令报错：working copy locked； try running ‘svn cleanup‘ on the root of the working copy

前言

可能使用git 管理代码的公司比较多，造成使用svn的，在遇到问题后，解决的途径只能靠外网资料，以及官方文档。

问题

就如标题描述一样，working copy locked; try running ‘svn cleanup’ on the root of the working copy。相信大家看到这样的错误提示可能很高兴，毕竟给出了解决方案。直接执行svn cleanup就解决了。
我们可以查看svn cleanup用法：

haha，真这么简单！！
可能不会。
执行svn cleanup 后，紧接着就是这两句：
working copy locked; try running ‘svn cleanup’ on the root of the（提示根目录） working copy。
sqlite：unable to open database file。

怎么办？

按照它提示方法，cd 到指定的路径下，执行svn cleanup。
哈哈，还是这个错。
继续cd …/，报这不是个working copy。
嗨，白忙活了。撤吧。直接删掉这个本地目录吧，很直接。当然解决了。

又出现了！！

程序员万能重启大法，很有效。
可不可能每次workspace locked 后都重新拉一个本地目录吧。很烦。也很不方便。如果是在你准备commit code时，那种烦躁不言而喻。如果你习惯在编程时使用vs code远程的话，可能简单点，因为它自带的cache功能。你重新拉代码后，使用ctrl + z可以回退到你删除的提交记录。但是这毕竟不是你个人的产品，你的兄弟们也在不停的造代码呀。你这一ctrl + z,它的code就被cover了。
当然，这也不恐怖，老手总是胸有成竹，我可以diff呀，实在不行，我重新写cover一遍不就行了。代码量比较一下，看是动他的，还是你的，更可以显示出你的老练。

这是正道？？

作为一个老手，肯定不会这么粗糙。（有第一次粗糙的经历就行了）
问题还是需要解决呀！！
心里第一个想法就是看看我两谁点更硬，它硬点，就看是否是在不能接受花费的时间成本里，不在暂时放弃呗。
大丈夫能屈能伸。还可以开口问问同事。同事不能处理，又查不到的时候，你就坚定的认为你的环境有问题就行了，毕竟同一套代码，他是过的，嘻嘻。
查了一下，感觉靠谱的，这展示一下连接：https://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/
有兴趣的朋友可以看看，因为我下面真正解决这个问题，不是采用这个方法，但是他给我提供了解决思路，过程中发现了端倪。
按照它的说法，我需要下载一个sql客户端工具，https://www.sqlite.org/download.html
好吧，我是下载了，可它不能直接拉进xshell,我又不想使用xftp,难得下！！我的虚拟机是centos，使用yum下载sqlite就行。
下面闹笑话了。
空间不足，/tmp没有空间了，下不了了。源直接就没开启，那就删删空间吧。
不下不知道，一下…
它就在环境里面乖乖躺着。（真是忘了）

是不是真的要操作！！

凭着多年敏锐的嗅觉。
是不是内存不足，引起的svn cleanup命令执行不足的问题？？
可能它开始运行时，检测内存空间。
怎么不直接报相应的错那。
郁闷！！！
再次输入熟悉的命令svn cleanup。

该高兴了吧，等等，谨慎一点，

那是不是编译失败，导致working copy locked？

事实证明，本地库在编译过程中，由于空间不足，编译失败，导致working copy locked：

嗨，不直接报空间不足，大bug.

总结

编译不过，又没有明显提示的，就需要注意空间咯。
自己在写这种脚本时，检测是否有空间，就显得很重要了。