SVN错误-不是工作副本

最近，我们的svn服务器已更改，我们进行了svn切换。

由于工作副本具有大量未版本控制的资源，因此工作副本被锁定，我们开始为svn下的所有文件夹逐文件夹切换。

但是在存储库的最高层，当我尝试更新文件时，得到了svn：工作副本'。锁定的错误，清理也无济于事。进行清理时，出现类似以下的错误-svn：“ content”不是工作副本目录

新鲜的结帐根本不是一种选择。还有其他方法可以清除和释放锁并完全进行开关操作吗？

编辑： JesperE的答案的最后一段

如果在进行递归“ svn清理”时得到“非工作副本”，我的猜测是您有一个目录应该是工作副本（即顶层的.svn目录如此），但缺少它的自己的.svn目录。在这种情况下，您可以尝试删除/移动该目录，然后进行本地更新

似乎是存储库中问题的解决方案。我已经识别出这些文件夹，并单独对这些特定文件夹进行了新的签出，而且哇，在随后的清理中释放了这些锁！非常感谢JesperE！

但是，我仍然无法弄清楚svn switch错误，该错误现在显示为：

svn：位于'svn：// repourl / reponame / foldername'的存储库具有uuid'm / reponame'，但WC具有'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

有任何想法吗 ？

如果执行递归操作时收到“非工作副本”，svn cleanup我想您有一个应该是工作副本的.svn目录（即顶层目录这样说），但它缺少自己的.svn目录。在这种情况下，您可以尝试删除/移动该目录，然后进行本地更新（即rm -rf content; svn checkout content）。

如果收到not a working copy错误，则表示Subversion无法.svn在其中找到合适的目录。检查是否在.svn目录中contents

如果可能，理想的解决方案是重新签出。

我svn: 'papers' is not a working copy directory以不同的方式陷入了类似的情况（），所以我以为我会发布自己的战斗故事（简体）：

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

糟糕！修复权限...然后：

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

甚至移开papers运行svn up（对OP都有效）也无法解决问题。这是我所做的：

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

那行得通。

我解决了

1. 复制受影响文件夹的备份
2. SVN还原受影响的文件夹
3. 从备份粘贴回文件

就我而言，问题是由于删除了.svn文件。

也许您只是复制了文件夹树并尝试添加最低的树。

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

在这种情况下，您必须在上一级提交目录。

解决方法：重命名不是“工作副本”的目录再次签出/更新/恢复该目录将文件从重命名目录移动到新的“提交更改”

原因：您对.svn目录下的某些文件进行了一些更改，这破坏了“工作副本”

如果您在新目录中创建文件，请使用“ svn add newdir”代替“ svn add newdir / newfile”，因为您需要添加目录。默认情况下，将添加目录内的所有文件。

我只是得到了“不是工作副本”，对我来说，原因是Unix上的Automouter。只是一个新的“ cd / path / to / work / directory”就可以了。

同样，我需要更新“ contrib”文件夹：

1. 将旧文件夹移出，
2. 复制了新的
3. 将.svn文件夹复制到每个新文件夹中（在我的情况下，仅三个）。

我也是我的情况，问题是由于删除了.svn文件夹。

解决了。

我尝试将.svn文件夹从子文件夹粘贴到根文件夹。有用！！！

这是我所做的：

1. 将trunk重命名为trunk_
2. 创建一个新的文件夹主干
3. 检出几个文件后，重新检出并中断该过程
4. 将文件从trunk_移到trunk
5. 进行svn清理
6. 做svn更新。这将更新文件的状态，然后将对所有文件进行版本控制。

我在svn diff操作中也遇到了这个问题，它是由不正确的文件路径引起的，应该添加'./'以指示当前文件目录。

svn：位于'svn：// repourl / reponame / foldername'的存储库具有uuid'm / reponame'，但WC具有'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

每个Subversion存储库都有一个唯一的标识符（uuid）。Subversion使用它来确保在执行诸如切换之类的操作时，存储库实际上是相同的。您可能应该将服务器上的uuid更改为与以前相同。

可能是工作副本格式不匹配吗？它在svn 1.4和1.5之间进行了更改，较新的工具会自动转换格式，但是较旧的工具将不再与转换后的副本一起使用。

您必须从项目中删除SVN基本文件（只读文件）。因此，您会收到此错误。

再次签出一个新项目，使用“ Winmerge”将旧的SVN项目的更改（如果有）与新的合并，并在最新签出中提交更改。

@JesperE 提到您需要更改uuid。以下内容将帮助您实现这一目标。

在SVN 1.5+上，您可以执行svnadmin setuuid; 然后，您可以使用svnlook uuid检查它是否已正确设置。在早期版本的SVN上，这是一个艰巨的过程。参见http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

此外，“ m / reponame”的UUID看起来可疑。我认为它应该是像工作副本一样的十六进制格式的数字，所以也许此操作将全面改善:-)

[我最初评论@JesperE的答案，但创建此答案的目的是使其对人们更明显，对Google更有帮助。此后，我删除了我的评论。]

遇到同样的问题，原来我们在同一台计算机上安装了Slik 1.6.2和Tortoise。Tortoise已更新（并更新了工作副本），但Slik尚未更新，因此Tortoise可以正常工作，但是命令行失败并显示以下内容：

svn：“。” 不是工作副本目录

删除Tortoise和Slik，然后在启用命令行工具的情况下重新安装Tortoise，这对我来说已解决。

对于Mac：-从服务器端签出，然后将打开一个新窗口，从本地计算机中选择目录，然后将所有代码放入所选文件夹中，然后打开svn本地并添加并提交项目

今天，我/FILE_NAME/ is not a working copy早上发现了同样的问题，我花了两个多小时来解决。经过长时间的RND和谷歌搜索之后，我找到了一些解决方案CHECKOUT。

1. CHECKOUT从SUBVERSION本地到新项目。
2. 更改Java文件中的某些代码，然后提交项目。
3. 对我有用。

希望对您有帮助。

最近我在使用其他开发人员Mac时遇到了同样的情况，问题是；首先，我需要输入get repo path到终端，但是我没有输入，而是说您的用户名和密码是什么。

我只是遇到.svn目录位于另一台计算机上的nfs服务器上，而nfs客户端未运行文件锁定服务（lockd）的情况。

svn: E155007: '/mnt/svnworkdir' is not a working copy

这一次消失了 lockd在nfs客户端主机上启动，了。

当锁定文件遇到麻烦时，subversion似乎可以提供更好的错误消息。这是Subversion 1.10.0

我从同一个项目进行了新的签出到另一个位置，然后从其中复制了.svn文件夹，并替换为旧的.svn文件夹。之后，调用了svn更新功能，所有内容均已正确同步到最新。

删除本地计算机中存在的.svn文件夹。按Windows图标并键入.svn，删除整个文件夹。它为我工作。