如果你在做递归的svn清理时得到了一个“非工作副本”，你可能有一个子目录，它应该是一个工作副本(即顶层的.svn目录这么说)，但是子目录缺少它自己的.svn目录。

在这种情况下，您可以移动或删除该目录，然后进行本地更新。若要删除该目录，

rm -rf content
svn checkout content

警告:rm -rf将永久删除文件夹内容。

如果您得到一个not a working copy错误，这意味着Subversion无法在content子目录中找到正确的.svn目录。检查内容中是否有.svn目录。

如果可能的话，理想的解决方案是重新结账。

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项目的更改(如果有的话)与新项目合并，并在最近的签出中提交更改。

处理:

重命名不是“工作副本”的目录。 再次签出/更新/恢复此目录。 将重命名目录中的文件移动到新目录中。 提交更改。

原因:

您对.svn目录下的一些文件做了一些更改，这破坏了“工作副本”。

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

在SVN 1.5+上，可以执行svnadmin setuuid;然后，您可以使用svnlook uuid检查它是否被正确设置。在SVN的早期版本中，这是一个比较困难的过程。请参见管理存储库uuid。

此外，“m/reponame”的UUID看起来可疑。我相信它应该是一个十六进制的数字，就像工作副本一样，所以也许这个动作会全面改善事情:-)

我以不同的方式进入了类似的情况(svn: 'papers'不是一个工作拷贝目录)，所以我想我将发布我的战斗故事(简化):

$ 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

甚至把文件移开，运行svn up(对OP有效)也没能解决问题。以下是我所做的:

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

这工作。

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

如果您在一个新目录下创建了一个文件，请使用'svn add newdir/newfile'而不是'svn add newdir'，因为您需要添加目录。默认情况下，将添加该目录中的所有文件。

我通过

复制受影响文件夹的备份 SVN恢复受影响的文件夹 从备份中粘贴回文件

在我的情况下，问题是由于删除。svn文件。

同样，我需要更新一个'contrib'文件夹:

把旧文件夹移出来， 复制一个新的 将.svn文件夹复制到每个新文件夹中(在我的例子中只有三个)。

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

解决了。

也许你只是复制了文件夹树，并试图添加最低的一个。

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

在这种情况下，你必须在上层提交目录。

我也有同样的问题。结果我们在同一台机器上有SlikSVN 1.6.2和TortoiseSVN。Tortoise已经更新了(也更新了工作副本)，但是SlikSVN没有，所以Tortoise工作正常，但是命令行失败了:

svn:”。不是工作副本目录

删除TortoiseSVN和SlikSVN，然后用命令行工具重新安装TortoiseSVN，为我修复了这个问题。

我尝试将.svn文件夹从子文件夹粘贴到根文件夹。它的工作原理!

这就是我所做的:

将trunk重命名为trunk_ 创建一个新的文件夹主干 在签出少量文件后，重新签出并中断该过程 将文件从trunk_移动到trunk 执行svn cleanup 执行svn update。这将更新文件的状态，然后所有文件都将进行版本控制。

我在svn diff操作中也遇到了这个问题。这是由错误的文件路径引起的。你应该加上‘。/'表示当前文件目录。

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

今天早上我发现同样的问题，/FILE_NAME/ is not a working copy，我花了两个多小时才解决。经过长时间的RND和谷歌，我找到了一些解决方案，那就是结帐。

作为一个新项目从Subversion签出到本地。 更改Java文件中的一些代码并提交项目。 这对我很管用。

删除本地机器中存在的.svn文件夹。按下windows图标并输入.svn，删除整个文件夹。这对我很管用。

最近我在用另一家开发商的Mac。 我也遇到过同样的情况。问题是;首先，我需要在终端中输入获取存储库路径，但我没有。然后它会显示你的用户名和密码。

我刚刚遇到了这样一种情况:.svn目录位于另一台机器上的NFS服务器上，NFS客户端没有运行文件锁定服务(lockd)。

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

在NFS客户端主机上启动lockd之后，这个问题就消失了。

当Subversion无法锁定文件时，它似乎可以提供更好的错误消息。这是Subversion 1.10.0

我从相同的项目到不同的位置进行了新的签出，从中复制了.svn文件夹，并用旧的.svn文件夹替换它。

之后，我调用svn更新函数，所有内容都正确同步到最新。

当我试图从一个大型SVN项目中检出部分源代码时，我也遇到了同样的错误:

svn co --depth empty svn://tug.org/texlive/trunk/Build
cd Build
svn update --set-depth infinity --parents ./source/texk/web2c

在这里，父母是成功的关键。

我就犯了这个错误。我注意到我进错目录了。一旦我恢复到SVN Trunk目录，问题就解决了。

当我在代码上执行mvn release:prepare时，我看到了这个错误。就我而言，我已经将项目从SVN迁移到GitHub，并从GitHub克隆了源代码。但是在我的pom.xml文件中，我没有将SCM位置从SVN URL更新到GitHub URL，导致工作目录不匹配。

纠正URL到GitHub位置帮助我解决了这个问题。