在我的例子中，一台运行TortoiseSVN的Windows 7机器无法完全重命名文件夹。任何清理、更新或重命名操作的组合都不能解决这个问题。文件夹最初是用不同的case创建的，Tortoise或Subversion不会将其更改为存储库中的内容。

我的解决方案是:

通过Windows资源管理器复制文件夹(不带Subversion控件) 文件)在项目之外。 通过TortoiseSVN删除并提交文件夹。 通过Windows资源管理器将文件夹复制回正确的(当前)名称。 通过TortoiseSVN将文件夹添加回存储库。

我在每一步之后都进行了清理。糟糕的解决方法，但对我很有效。

我的根目录中有一个文件把它弄乱了。(没有锁文件，svn清理失败等)我的整个签出是> 2GB，网速较慢，所以再次检查所有内容对我来说不是一个很好的选择。

对我有用的是:

还原&还原的变化 搞砸了工作副本(#1)。 又查了一份回购文件 (2)——depth为空 添加和 在new中提交文件 工作副本(#2)。 已在 原始工作副本(#1)。

对我来说似乎又恢复正常了。

在对项目结构进行更改时，首先可以通过使用svn copy和svn move etc命令来避免这类问题。请记住，svn只检查已经添加到subversion的文件中的更改，而不检查物理目录结构的更改。请参阅http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html

此外，在提交更改时，svn首先在todo列表中存储更改的“摘要”。在执行此todo列表中的svn操作时，它会锁定该文件，以防止在执行这些svn操作时发生其他更改。如果svn的操作中途中断，比如崩溃，文件将保持锁定状态，直到svn完成todo列表中的操作。可以使用svn cleanup命令“重新激活”。请参阅http://svnbook.red-bean.com/en/1.7/svn.tour.cleanup.html

我在答案中没有看到这个问题的一个原因是，更新或签出可能已经使用其他用户/权限完成，例如使用$sudo。

查看您的.svn文件夹，其中将有一个名为lock的文件。删除该文件，您将能够更新。每个子目录的.svn目录下可能存在较多的锁文件。它们也需要删除。这可以作为批处理从命令行非常简单地完成，例如。

find . -name 'lock' -exec rm -v {} \;

注意，您正在手动编辑.svn文件夹中的文件。他们被放在那里是有原因的。这个理由可能是错误的，但如果不是的话，你可能会破坏你的本地副本。

来源:http://www.svnforum.org/2017/viewtopic.php?p=6068

最简单的方法是显示隐藏文件夹，然后打开. svn文件夹。您应该看到一个名为“lock”的零KB文件，删除它将解决这个问题