如何修复SVN中的“缺少工作副本管理区域”？

我手动删除了刚刚在存储库中离线添加的目录。我无法还原目录。

任何尝试进行更新或提交的尝试都会失败，并显示以下内容：

"blabla/.svn" containing working copy admin area is missing.

我知道为什么，但是仍然可以解决此问题。

我不想检出整个存储库并手动添加更改，这将需要几个小时。

据此：http : //www.devcha.com/2008/03/svn-directory-svn- contains-working.html

将文件夹“ blabla”检出到其他位置，然后将其.svn文件夹复制回原始的“ blabla”。

首先，我遇到了类似的情况，并使用了svn --force delete __dir__。那为我解决了这个问题。然后，我像往常一样继续使用我的工作副本。

我要解决的问题是删除有问题的文件夹的本地副本，然后再svn update直接做一个父文件夹。

修复正确。

您可以尝试签出父目录的新副本吗？

编辑：更具体一点，我的意思是建议上一层并删除包含的目录。然后做一个

svn update --set-depth infinity

替换目录。

我将目录添加到svn，然后不小心删除了其中的.svn文件夹。

我用了

svn delete --keep-local folderName

解决我的问题。

我只是做了'svn revert / blabla'并且工作了，文件夹又回来了，我可以svn删除它

当我尝试将目录添加到资源库时，出现错误“目录'blah / .svn'，其中包含工作副本管理区域丢失”，但没有足够的文件系统特权来执行此操作。该目录尚未在存储库中，但在添加失败后声称已受版本控制。

将父目录的副本检出到另一个位置，并替换工作副本的父目录中的.svn文件夹，这使我能够成功添加和提交新目录（当然，在修复文件权限之后）。

我们使用Maven和SVN。目标目录错误签入SVN导致此错误。如果此提示可以帮助任何人，则删除该内容将修复所有问题。

我试图svn rm --force /path/to/dir无济于事，但最终还是运行了svn up，它为我修复了它。

最近，当我的SVN全局变量中的设置排除文件时，出现了此错误。该错误特别令人讨厌，因为我也直接从存储库中删除了文件-这意味着上述解决方案拒绝将无法正常工作。在这种情况下，从我从SVN删除的目录中手动删除.svn目录可以使我运行更新，然后允许我进行提交。

当我尝试切换“ C：\ superfolder”时，我遇到了同样的问题

错误讯息：

Directory 'C:\superfolder\subfolder\.svn'
containing
working copy admin area is missing
Please execute the 'Cleanup' command.

尝试执行“清理”后，出现以下错误：

 Cleanup failed to process the following paths:
 C:\superfolder\
'C:\superfolder\subfolder\' is not a working copy directory

解：

1. 删除文件夹“子文件夹”
2. 清理文件夹“ superfolder”
3. 尝试再次切换文件夹“ superfolder”

这对我有用。请让我知道它是否也适合您。

我最近有这个错误。这是由于root在目录中拥有几个文件而导致此错误。

更改权限后，一切正常。

从您的帖子中了解的不多。我的解决方案是

1. 剪切有问题的文件夹，然后复制到某个位置。
2. 从Subversion获取解决方案到另一个工作目录（只是一个新目录）。
3. 将您保存的文件夹添加到新的工作副本中，并将其添加为“现有项目”（如果是我的项目）。
4. 承诺;

我有这个问题。只需将blabla临时移动到另一个位置，告诉svn将其还原，然后再将其移回即可。它被视为新的添加。简单！

最简单的帮助我：

rm -rf _dir_in_question_
svn up

如果您在有问题的目录中进行了更改，那么这对您来说不是一个很好的解决方案。

当我用较新的版本替换第三方API库时遇到了这个问题，这里的任何解决方案都不对我真正有用，因为我想用本地版本替换SVN版本。我的解决方案如下：

1）将有问题的文件夹移到我的主目录，将其从SVN中删除并提交：

mv foldercausingproblem ~/
svn --force delete foldercausingproblem
svn commit --message "Temporary removing folder with old API"

2）放回文件夹，将其添加到SVN并再次提交：

mv ~/foldercausingproblem ./
svn --force add .
svn commit --message "Finally all working!"

不得不提交两次，这有点恼人，但似乎效果很好。

万一有人想要另一个解决方案：

1. 以“ foldername2”的身份签入新文件夹
2. 进入Tortise SVN回购浏览器
3. 将“ foldername2”重命名为“ foldername”
4. 在Windows资源管理器中进行更新

希望它能帮助某人。

-EV

对我来说，当我俩都发生相同的问题时：

• 删除（--force）.map文件
• 将* .map添加到svn:ignoreviasvn propedit svn:ignore .

我的解决方案是：

1. 撤消对该属性的更改
2. 提交对文件的更改
3. 签出存储库的新副本（糟糕！）
4. 更改属性并提交

当我尝试向svn添加目录时遇到了这个问题。我通过进入回购浏览器解决了这个问题。右键单击左侧窗口，选择添加文件夹，然后直接在回购浏览器中添加目录。

然后，我在本地删除了该目录（当然是在备份之后），进行了清理和svn更新，一切再次正常运行。

首先，将项目检出到文件夹中的系统中。然后从冲突项目中删除.svn文件夹，并从新的checkout文件夹复制.svn文件夹，然后粘贴到您的工作副本文件夹中。然后问题解决了。

我经历过的一个常见任务是必须暂存一个repo目录并将其复制到另一个repo-两者都在SVN下，并且都称为相同名称。对我有效的方式如下：

svn --force delete PROBLEMATIC-DIR
svn export "https://OLD REPO-A/ new-repo-A"
svn add new-repo-A
svn commit new-repo-A