首页 文章

SVN错误 - 不是工作副本

提问于
浏览 次
206

最近我们的svn服务器被更改了，我们做了一个svn开关 .

由于工作副本有大量的无版本资源，工作副本被锁定，我们开始在文件夹下为svn下的所有文件夹切换文件夹，这完全正常 .

但是在存储库的最顶层，当我尝试更新文件时，我得到了svn：工作副本'.'锁定错误，清理也无济于事 . 当我进行清理时，我会收到类似这样的错误 - svn：'content'不是工作副本目录

新鲜的结账不是一个选择 . 有没有其他方法可以清理和释放锁并完全切换？

EDIT: JesperE答案中的最后一段

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

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

但是，我仍然无法弄清楚现在读取的svn开关错误，

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

有任何想法吗 ？

svn

21 回答

  • 0

    如果你在做一个递归 svn cleanup 时得到一个"not a working copy"，我的猜测是你有一个应该是一个工作副本的目录（即顶层的 .svn 目录这样说），但它缺少自己的 .svn 目录 . 在这种情况下，您可以尝试删除/移动该目录，然后进行本地更新（即 rm -rf content; svn checkout content ） .

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

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

    回复于
  • 0

    我以不同的方式陷入了类似的情况（ 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工作）并没有't fix it. Here'我做了什么：

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

    那很有效 .

    回复于
  • 0

    我解决了

    • 复制受影响文件夹的备份

    • SVN还原受影响的文件夹

    • 从备份中粘贴文件

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

    回复于
  • 5

    也许你刚刚复制了文件夹树并尝试添加最低版本 .

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

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

    回复于
  • 1

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

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

    回复于
  • 0

    我刚刚得到“不是工作副本”，对我而言，原因是Unix上的Automouter . 只需一个新的“cd / path / to / work /目录”就可以了 .

    回复于
  • 0

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

    回复于
  • 0

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

    • 移出旧文件夹，

    • 复制新的

    • 将.svn文件夹复制到每个（在我的情况下只有三个）新文件夹中 .

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

    解决了 .

    回复于
  • 1

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

    回复于
  • 121

    这就是我做的：

    • 将trunk重命名为trunk_

    • 创建一个新的文件夹主干

    • 重新签出并在签出几个文件后中断该过程

    • 将文件从trunk_移动到trunk

    • 做svn清理

    • 做svn更新 . 这将更新文件的状态，然后所有文件都将被版本化 .

    回复于
  • 1

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

    回复于
  • 1

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

    每个subversion repo都有一个唯一的标识符（uuid） . Subversion使用它来确保在执行切换等操作时repo实际上是相同的 . 您应该将服务器上的uuid更改为与以前相同 .

    回复于
  • 0

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

    回复于
  • 1

    您必须已从项目中删除了SVN基本文件（这些文件是只读文件） . 应有对此你得到这个错误 .

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

    回复于
  • 6

    @JesperE mentions你需要更改uuid . 以下内容可帮助您实现这一目标 .

    在SVN 1.5上，你可以做svnadmin setuuid;然后你可以检查它是一个更难的过程 . 见http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

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

    [我最初评论@JesperE's answer，但创建了这个答案，使其对人们更明显，对谷歌更有帮助 . 我已经删除了我的评论 . ]

    回复于
  • 0

    有同样的问题，结果我们在同一台机器上有Slik 1.6.2和Tortoise . 乌龟已更新（并更新了工作副本）但Slik没有，所以Tortoise工作正常，但命令行失败了：

    svn：' . '不是工作副本目录

    删除Tortoise和Slik，然后使用命令行工具重新安装Tortoise为我修复了这个问题 .

    回复于
  • 0

    对于mac： - 从服务器端进行结账，将打开一个新窗口，从本地机器中选择目录，而不是将所有代码放入所选文件夹，然后打开svn本地端并添加并提交项目

    回复于
  • 1

    今天早上我发现了同样的问题 /FILE_NAME/ is not a working copy ，我花了两个多小时来解决它 . 经过很长一段时间的RND和谷歌我发现了一些解决方案，那就是 CHECKOUT .

    • CHECKOUT 从 SUBVERSION 到本地作为新项目 .

    • 更改java文件中的一些代码并执行COMMIT项目 .

    • 这对我有用 .

    希望它对你有所帮助 .

    回复于
  • 3

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

    回复于
  • 0

    最近我使用其他开发人员Mac我有同样的情况，问题是;首先我需要输入get repo路径到终端，但我没有，而不是说你的用户名和密码是什么 .

    回复于
  • 46

    我刚遇到一个案例，其中.svn目录位于另一台机器上的nfs服务器上，而nfs客户端没有运行文件锁定服务（ lockd ） .

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

    一旦_f33322_在nfs客户端主机上启动，这就消失了 .

    看起来subversion在锁定文件时遇到问题会产生更好的错误信息 . 这是颠覆1.10.0

    回复于

相关问题