我在一个工作文件夹中有很多更改，在尝试进行更新时出错了。
现在当我发出'svn cleanup'时，我得到:
>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control
MemPoolTests.cpp是另一个开发人员添加的新文件，在更新中被删除了。以前我的工作文件夹里不存在。
我能做些什么来尝试并继续前进，而不必签出存储库的新副本吗?
澄清:感谢您提出的关于将目录移出并删除一个新副本的建议。我知道这是一个选项，但这是我想避免的，因为有许多更改嵌套在几个目录深处(这应该是一个分支…)
我希望有一种更积极的方式来做清理，也许以某种方式迫使文件SVN有麻烦回到一个已知的状态(我尝试删除它的工作副本…这并没有帮助)。
当前回答
我只是从~\. xml文件中删除了svn-xxxxxxxx文件。Svn \tmp文件夹，其中XXXXXXXX是数字。
其他回答
我也遇到过同样的问题。在网上搜了一下，找到了下面这篇文章。然后意识到我的登录用户与我用来安装SVN的用户不同，这基本上是一个权限问题。
我也有同样的问题。我不能承诺，清理工作就会失败。
使用命令行客户端，我能够看到一条错误消息，表明它无法将文件从.svn/props移动到.svn/prop-base。
我查看了特定的文件，发现它被标记为只读。删除只读属性后，我能够清理文件夹并提交我的更改。
这个答案只适用于1.7之前的版本(感谢@ŁukaszBachman)。
Subversion将它的信息存储在每个文件夹中(在.svn中)，所以如果你只是处理一个子文件夹，你不需要签出整个存储库-只需要签出已经中断的文件夹:
cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir
这将为您提供borked文件夹的良好工作副本，但您仍然在borked_dir.bak中备份了更改。同样的原则也适用于Windows/TortoiseSVN。
如果在独立文件夹中有更改，请查看
svn checkout -N borked_dir # Non-recursive, but deprecated
or
svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'
$ ls -la .svn
$ rm -f .svn/lock
然后
$ svn update
希望能有所帮助
我遇到一个问题，在更新之后，SVN显示一个文件夹是冲突的。奇怪的是，这只能通过命令行看到- TortoiseSVN认为这一切都很好。
#>svn st
! my_dir
! my_dir\sub_dir
SVN清除，SVN恢复，SVN更新和SVN解决都无法解决这个问题。
我最终解决的问题如下:
在.svn目录中查找“sub_dir” 使用RC ->属性取消选中条目文件上的“只读”标志 打开条目文件，删除行“unfinished…”和相应的校验和 保存，并重新启用只读标志 对my_dir目录重复此操作
在那之后，一切都很好。
注意，我没有任何局部变化，所以我不知道如果你有风险。我没有使用其他人建议的删除/更新方法——我是在my_dir/sub_dir/sub_sub_dir目录上尝试该方法(开始时具有相同的症状)才陷入这种状态的——所以我不想冒险让事情再次变得更糟!
不是很切题，但如果有人像我一样看到这篇文章，可能会有帮助。
