当'svn cleanup'失败了吗?

我在一个工作文件夹中有很多更改，在尝试进行更新时出错了。

现在当我发出'svn cleanup'时，我得到:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp是另一个开发人员添加的新文件，在更新中被删除了。以前我的工作文件夹里不存在。

有没有什么我可以做，以尝试和向前没有必须签出一个新的副本的存储库?

谢谢你关于移动目录的建议，并拿出一个新的拷贝。我知道这是一个选项，但这是我想避免的，因为有许多更改嵌套在几个目录深处(这应该是一个分支…)

我希望有一种更积极的方式来做清理，也许以某种方式迫使文件SVN有麻烦回到一个已知的状态(我尝试删除它的工作副本…这并没有帮助)。

359048 次浏览
小开

如果以上都失败了:

  1. 签出到一个新文件夹中。
  2. 复制修改过的文件。
  3. 检查回来。
  4. 在删除旧文件夹并使用新文件夹之前，将旧文件夹压缩到某个地方(你永远不知道+偏执狂是好的)。
小开

这个答案只适用于1.7之前的版本(感谢@ŁukaszBachman)。

Subversion将它的信息存储在每个文件夹中(在.svn中)，所以如果你只是处理一个子文件夹，你不需要签出整个存储库-只需要签出已经中断的文件夹:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

这将为您提供borked文件夹的良好工作副本，但您仍然在borked_dir.bak中备份了更改。同样的原则也适用于Windows/TortoiseSVN。

如果在独立文件夹中有更改，请查看

svn checkout -N borked_dir   # Non-recursive, but deprecated

或

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'
小开

我也有同样的问题。我不能承诺，清理工作就会失败。

使用命令行客户端，我能够看到一个错误消息，表明它无法将文件从.svn/props移动到.svn/prop-base。

我查看了特定的文件，发现它被标记为只读。删除只读属性后，我能够清理文件夹并提交我的更改。

小开

当一切都不能重新开始的时候……

我删除了.svn目录中的日志文件(我也删除了.svn/props-base中的违规文件)，进行了清理，并恢复了更新。

小开

它可能并不适用于所有情况，但当我最近遇到这个问题时，我的“解决方案”是升级系统上的Subversion包。我一直跑1.4。当我升级到最新版本(我的版本是1.6.6)时，签出工作正常。

(我确实尝试重新下载，但签出到一个干净的目录总是挂在同一个位置。)

小开

您可能遇到两个文件名仅大写不同的问题。如果遇到此问题，创建另一个工作副本目录并不能解决问题。

当前的Windows(即蹩脚的)文件系统根本不理解Filename和FILEname之间的区别。你有两个可能的解决方案:

  1. 在使用真实文件系统(基于unix)的平台上签出，重命名文件，并提交更改。
  2. 当您绑定到Windows时，您可以在Eclipse SVN存储库浏览器中重命名文件，该浏览器能够识别差异并在那里重命名文件。
  3. 您还可以使用svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename从任何命令行SVN客户端远程重命名有问题的文件
小开

只读锁定有时发生在Windows网络驱动器上。尝试断开连接并重新连接。然后清理和更新。

小开

如果问题是大小写敏感(签出到Mac和Windows时可能会出现问题)，并且你没有签出到*nix系统的选项，下面的方法应该可以工作。这是从头开始的过程:

% svn co http://[domain]/svn/mortgages mortgages

(接着是结帐……然后……)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

在这里，SVN试图检出两个名称相似、仅大小写不同的文件——Header_3_noBookmark.gif和Header_3_nobookmark.gif。Mac文件系统默认为大小写不敏感，在这种情况下会导致SVN阻塞。所以…

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

然而，正如我们所知，运行svn cleanup是行不通的。

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gif不是这里的问题，它只是不能从上一个错误移到下一个文件。所以我删除了目录中除了.svn之外的所有文件，并删除了SVN日志。这使得清理工作得以进行，这样我就可以检出并重命名有问题的文件。

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

在此之后，我能够回到项目的根目录，并运行svn up来检查它的其余部分。

小开 
$ ls -la .svn
$ rm -f .svn/lock

然后

$ svn update

希望能有所帮助

小开

在经历了这里引用的大多数解决方案之后，我仍然得到了错误。

问题是不区分大小写。签出具有两个同名但大小写不同的文件的目录会导致问题。例如，approationtest .java和approationtest .java不应该在同一个目录中。一旦我们删除了其中一个文件，这个问题就消失了。

小开

(在尝试移动文件夹和执行新的签出之前。)

删除有问题的文件所在的文件夹-是的，甚至.svn文件夹，然后 在最上面的/ parent文件夹上执行svn cleanup
小开

我遇到一个问题，在更新之后，SVN显示一个文件夹是冲突的。奇怪的是，这只能通过命令行看到- TortoiseSVN认为这一切都很好。

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup， svn revert， svn update和svn resolve都无法修复此问题。

我最终解决的问题如下:

  • 在.svn目录中查找“sub_dir”
  • 使用RC ->属性取消选中条目文件上的“只读”标志
  • 打开条目文件，删除行“unfinished…”和相应的校验和
  • 保存，并重新启用只读标志
  • 对my_dir目录重复此操作

在那之后，一切都很好。

注意，我没有任何局部变化，所以我不知道如果你有风险。我没有使用其他人建议的删除/更新方法——我是在my_dir/sub_dir/sub_sub_dir目录上尝试该方法(开始时具有相同的症状)才陷入这种状态的——所以我不想冒险让事情再次变得更糟!

不是很切题，但如果有人像我一样看到这篇文章，可能会有帮助。

小开

Subclipse被Windows真正邪恶的锁定行为弄糊涂了。破解是你的朋友。这可以找到锁定的文件并强制释放锁。

小开

我刚刚在64位的Windows 7上遇到了同样的问题。我以管理员身份运行控制台，并从问题目录中删除了.svn目录(得到了关于日志或其他内容的错误，但忽略了它)。然后，在资源管理器中，我删除了不再显示为版本控制下的问题目录。然后，我运行了一个更新，事情按照预期进行。

小开

我也有同样的问题。对我来说，原因是与EasySVN和(TortoiseSVN或SVN)的冲突。我有自动更新和提交与EasySVN(这是不工作)。

当我关闭此功能时，我无法清理、提交或更新。上面的解决方案都没用，但是重新启动可以:)

小开

每当我遇到类似的问题时，我使用rsync(注意:我使用Linux或Mac OS X)来帮助解决:

# Go to the parent directory
cd dir_above_borked


# Rename corrupted directory
mv borked_dir borked_dir.bak


# Checkout a fresh copy
svn checkout svn://... borked_dir


# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/


# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/
这样您就有了一个新的签出，但是使用相同的工作文件。

小开

在SVN 1.7中，情况发生了变化，删除. SVN目录中的日志文件的流行解决方案在迁移到数据库工作复制实现后不再可行。

以下是我做的似乎有效的方法:

  1. 删除工作副本的.svn目录。
  2. 在一个新的临时目录中启动一个新的签出。
  3. 取消签出(我们不想等待所有东西都被拉下)。
  4. 对取消的签出运行清理。
  5. 现在我们有了一个新的.svn目录和一个干净的数据库(虽然没有/很少的文件)
  6. 将这个.svn复制到旧的、损坏的工作目录中。
  7. 运行svn update，它将使新的部分.svn目录与旧的工作目录保持一致。

这一切都有点令人困惑，就流程而言。本质上，我们所做的是删除损坏的.svn，然后为相同的签出路径创建一个新的.svn。然后，我们将这个新的.svn移到旧的工作目录中，并将其更新到repo。

我刚刚在TSVN中这样做了，它似乎工作得很好，不需要完整的签出和下载。

杨晨

小开

我也遇到过同样的问题。经过一些搜索在互联网上找到下面的文章。然后意识到我的登录用户与我用来安装SVN的用户不同，这基本上是一个权限问题。

小开

看一看

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

以上链接的修复摘要(感谢Anuj Varma)

  1. 安装sqlite命令行shell (sqlite-tools-win32) from http://www.sqlite.org/download.html

  2. sqlite3 .svn/wc.db "select * from work_queue"

SELECT应该显示您的违规文件夹/文件作为 工作队列中。你需要做的就是从工作中删除这个项目 队列。< / p >

  1. sqlite3 .svn/wc.db "delete from work_queue"
< p >就是这样。现在，您可以再次运行清理—它应该可以工作。或者你 可以直接进入你在被提示之前正在做的任务 运行清理(添加新文件等)

小开

我试图通过控制台做svn cleanup，得到一个错误，如:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

所以我手动创建了这个文件(空)，并再次执行svn cleanup。这次做得不错。

小开

我做了sudo chmod 777 -R .来改变权限。如果没有sudo，它将无法工作，给我带来与运行其他命令相同的错误。

现在你可以执行svn update或其他操作，而不必废弃整个目录并重新创建它。这是特别有用的，因为您的IDE或文本编辑器可能已经打开了某些选项卡，或者有同步问题。您不需要使用此方法废弃并替换您的工作目录。

小开

我将同事的.svn目录复制到我的目录中，然后更新我的工作副本，从而解决了这个问题。这是一个很好的、快速的、干净的解决方案。

小开

当我面对这个问题与TortoiseSVN (Windows)，我去Cygwin和运行'svn清理'从那里;它为我正确地清理，之后一切工作从TortoiseSVN。

小开

这里的回答没有帮助我，但是在再次检出项目之前，我关闭并打开Eclipse (subversion是我的SVN客户端)，问题消失了。

小开

我最近也遇到过这种情况。对我来说，诀窍是在选择“清理”后，在弹出的选项对话框中，选择“打破锁”，然后选择“确定”。它为我成功地清理了。

小开

在终端中运行svn cleanup命令(如果它在Eclipse中失败，这是我的情况):

~/path/to/svn-folder/$ svn cleanup

这里解释了我尝试了不同的解决方案，但是没有工作。

动作团队→更新到头部失败:

svn: E155004:“/home/user/path/to/svn-folder”下有未完成的工作项;先运行'svn cleanup'。

动作团队→清理失败，错误相同。

对我有效的解决方案:在终端中执行svn cleanup命令。

命令执行成功。

然后Eclipse中的团队→更新再次工作。

注意:我的SVN版本是1.9.3。

如果svn cleanup不起作用，也检查克里斯的回答。

小开

在之前的回答中有一些非常好的建议，但如果你在Windows上使用TortoiseSVN(一个好产品，但是…)时遇到问题，总是退回到命令行，首先做一个简单的“svn清理”。

在许多情况下，Windows客户端不会运行清理命令，但是使用SVN命令行实用程序可以很好地进行清理。

小开

最新版本(我使用的是1.9.5)通过在清理菜单上添加“打破锁”选项来解决这个问题。请确保在清理时选中了此复选框。

清理窗口

小开

当遇到类似的问题时，在存储库同步视图中手动合并有助于解决这个问题。

一个文件名与其他文件名冲突，它清楚地提到了这个问题。将新文件重命名为不同的名称可以解决这个问题。

小开

我刚刚从~\.svn\tmp文件夹中删除了文件svn-xxxxxxxx，其中xxxxxxxx是一个数字。

小开

我还遇到了清理失败的问题。最初我试图提交一些代码，但它说:

svn: E155004: '/my/path/to/files'中有未完成的工作项;先运行'svn cleanup'。

但当我试图清理的时候:

svn: E155007: '/my/path/to/files'不是工作拷贝目录

以我为例，结果是我在复习方面遇到了冲突。我的svn文件夹包含.mine、.r1和.r2文件。一旦我解决了冲突，清理工作就成功地运行了。


提交答案