这一直困扰着我一周。
SVN一直告诉我某个文件“does not exist in repository”。
精细。我们只是删除它。忘掉它。忽略它。随你。我并不关心这个文件（特别是如果它在夜间办理登机手续时仍然失败）。
最离奇的部分？ “还原”实际上会从存储库中恢复文件，所以它在那里（已损坏，可能是？）。
......这必须是锦上添花。如果我通过Windows资源管理器删除该文件，SVN将从存储库中恢复该文件，并在该状态之后存储库中不存在该文件。 WTF？
有没有人知道如何摆脱这个？
我已经尝试过清理，转换，删除以及其他任何可以想象的事情，但这个让我感到难过。
感谢您提供的任何提示......
答案 0 :(得分：17)
您最有可能损坏了本地工作副本，例如：通过移动文件夹或您使用Windows资源管理器执行的其他操作，但应该通过TortoiseSVN上下文菜单完成。 .svn文件夹中的信息现在不再与工作副本的状态相匹配，这使Subversion感到困惑。
要解决此问题，请使用Windows资源管理器（不使用TortoiseSVN）删除工作副本中的父文件夹（“Originals”）。然后在工作副本的根目录下执行TortoiseSVN“更新”。这应该按工作顺序恢复文件夹。
另一种选择是完全丢弃您的工作副本并进行新的结帐。
请注意，Subversion（1.7）的下一个版本将通过将所有元数据集中在根目录下的单个.svn文件夹中来减少损坏工作副本的机会。
答案 1 :(得分：0)
我在使用损坏的工作副本时遇到了类似的问题。有时，工作副本有很多未决的更改，但无法签入。要解决这个问题，我使用以下方法（svn 1.7 +）：
答案 2 :(得分：0)
我遇到了类似的问题，其中我有一个文件夹，例如＆＃34; FolderA＆＃34;即使我已删除它，它仍然在svn更新中始终显示。 它甚至不会显示在文件夹列表中，但svn仍会识别它，就好像它存在一样。
我按照以下步骤操作：
1.在同一文件位置中创建svn给出错误的相同文件夹名称
2.将其添加到svn checkout。由于它给出了冲突错误，我使用svn选项解决了它
3.删除文件夹并提交我的svn。
错误已解决