在对项目结构进行更改时，首先可以通过使用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

你是否正在使用TortoiseSVN并且刚刚升级?我以前从1.4迁移到1.5时就遇到过这个问题，而且无法重新启动。(尝试重启)。

您需要重新启动的原因是缓存文件变得异常。

否则，要继续前进，将该工作副本导出到一个新文件夹(不要复制.svn隐藏文件夹)，重新签出项目，并将所有代码移回，然后继续提交。

我遇到了这样的问题，“清理”工作，但“更新”将继续失败。有效的解决方案是通过Windows资源管理器删除有问题的文件夹，而不是TortoiseSVN的删除(这将删除标记为提交到存储库的内容，然后我做了一个“签出”，从存储库中“更新”文件夹。

关于O/S删除和SVN删除之间区别的更多信息: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

值得注意的是:

当你TortoiseSVN→Delete一个文件时，它会立即从你的工作副本中删除，并在下次提交时在存储库中标记为删除。

And:

如果一个文件是通过资源管理器而不是使用TortoiseSVN上下文菜单删除的，提交对话框会显示这些文件，并允许你在提交之前从版本控制中删除它们。但是，如果您更新了工作副本，Subversion将发现丢失的文件并用存储库中的最新版本替换它。

一种方法是:

将编辑过的项目复制到另一个位置。 删除包含问题路径的文件夹。 通过Subversion更新包含的文件夹。 复制文件或根据需要合并更改。 提交

另一种选择是删除顶级文件夹并再次签出。希望不会发展到那种地步。

当我遇到这个问题时，我发现直接在问题路径上运行清理命令通常似乎可以工作。然后，我将再次从工作根目录运行清理，它将报错其他目录。我一直重复，直到它不再抱怨。

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

对我有用的是:

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

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