'svn cleanup' 失败时我该怎么办？

当重新开始不是一种选择时......

我删除了 .svn 目录中的日志文件（我还删除了 .svn/props-base 中的有问题的文件），进行了清理，然后继续我的更新。

---

SVN 1.7 发生了变化，删除 .svn 目录中的日志文件的流行解决方案在迁移到数据库工作副本实现时是不可行的。

这是我所做的似乎有效的事情：

删除工作副本的 .svn 目录。在新的临时目录中开始新的签出。取消结帐（我们不想等待一切都被拉下来）。对此取消的结帐运行清理。现在我们有了一个新的 .svn 目录，其中包含一个干净的数据库（尽管没有/很少的文件） 将此 .svn 复制到您损坏的旧工作目录中。运行 svn update 它应该使您的新部分 .svn 目录与您的旧工作目录同步。

这有点令人困惑，过程明智。本质上，我们所做的是删除损坏的 .svn，然后为相同的结帐路径创建一个新的 .svn。然后我们将这个新的 .svn 移动到我们的旧工作目录并将其更新到 repo。

我刚刚在 TSVN 中做了这个，它似乎工作正常，不需要完整的结帐和下载。

-乔迪

---

看一眼

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

上述链接的修复摘要（感谢 Anuj Varma）

从 http://www.sqlite.org/download.html sqlite3 .svn/wc.db "select * from work_queue" 安装 sqlite 命令行 shell (sqlite-tools-win32) SELECT 应该会显示您有问题的文件夹/文件作为工作队列的一部分。您需要做的是从工作队列中删除此项目。 sqlite3 .svn/wc.db "delete from work_queue" 就是这样。现在，您可以再次运行 cleanup - 它应该可以工作。或者您可以在提示运行清理（添加新文件等）之前直接执行您正在执行的任务

---

如果一切都失败了：

签出到一个新文件夹。将修改后的文件复制过来。重新检查。在删除旧文件夹并使用新文件夹之前，将旧文件夹压缩到某个地方（你永远不知道 + 妄想症是好的）。

---

最新版本（我使用的是 1.9.5）通过在清理菜单上添加“Break locks”选项解决了这个问题。只需确保在进行清理时选中此复选框即可。

https://i.stack.imgur.com/6A4el.png

---

此答案仅适用于 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'

---

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

然后

$ svn update

希望能帮助到你

---

我有同样的问题。我无法提交，清理会失败。

使用命令行客户端，我可以看到一条错误消息，指出无法将文件从 .svn/props 移动到 .svn/prop-base。

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

---

我尝试通过控制台执行 svn cleanup 并收到如下错误：

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

所以我手动创建了这个文件（空）并再次执行svn cleanup。这次它完成了。

---

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

当前的 Windows（即蹩脚的）文件系统根本无法理解 Filename 和 FILEname 之间的区别。您有两种可能的修复方法：

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

---

在终端中运行 svn cleanup 命令（如果它在我的情况下从 Eclipse 失败）：

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

我尝试了这里解释的不同解决方案，但没有一个有效。

行动团队 → 头部更新失败：

svn: E155004: '/home/user/path/to/svn-folder' 中有未完成的工作项；首先运行'svn cleanup'。

行动小组 → 清理失败并出现同样的错误。

对我有用的解决方案：在终端中运行 svn cleanup 命令。

命令成功。

然后 Eclipse 中的 Team → Update 再次工作。

注意：我的 SVN 版本是 1.9.3。

如果 svn cleanup 不起作用，还要检查 Chris's answer。

---

我有同样的问题。对我来说，原因是与 EasySVN 和（TortoiseSVN 或只是 SVN）的冲突。我使用 EasySVN 进行了自动更新和提交（这不起作用）。

当我关闭它时，我无法清理、提交或更新。上述解决方案均无效，但重新启动确实有效：)

---

Subclipse 对 Windows 真正恶魔般的锁定行为感到困惑。 Unlocker 是您的朋友。这可以找到锁定的文件并强制释放锁定。

---

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

---

如果问题是区分大小写（这在签出到 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 来检查它的其余部分。

---

（在您尝试移动文件夹并进行新的结帐之前。）

删除有问题的文件所在的文件夹 - 是的，甚至是 .svn 文件夹，然后在最顶部/父文件夹上执行 svn cleanup。

---

每当我遇到类似问题时，我都会使用 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/

这样你就有了一个全新的结帐，但使用相同的工作文件。对我来说，这总是很有魅力。

---

当我遇到 TortoiseSVN (Windows) 的这个问题时，我会转到 Cygwin 并从那里运行“svn cleanup”；它为我正确清理，之后一切都可以从 TortoiseSVN 运行。

---

我最近也遇到了。对我来说，诀窍是在选择“清理”后，在弹出的选项对话框中，选中“Break Locks”，然后选择“OK”。它为我成功清理。

---

我遇到了同样的问题。在 Internet 上进行一些搜索后，找到了 below article。然后意识到我登录的用户与我用来设置 SVN 的用户不同，基本上是权限问题。

---

上一个答案中有一些非常好的建议，但是如果您在 Windows 上遇到 TortoiseSVN 问题（一个很好的产品，但是......）总是回退到命令行并首先执行简单的“svn cleanup”。

在许多情况下，Windows 客户端不会运行清理命令，但使用 SVN 命令行实用程序进行清理可以正常工作。

---

我也有清理失败的问题。最初我试图提交一些代码，但它说：

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

但是当我试图清理时：

svn: E155007: '/my/path/to/files' 不是工作副本目录

就我而言，事实证明我遇到了修订冲突。我的 svn 文件夹包含 .mine、.r1 和 .r2 文件。一旦我解决了冲突，清理就会成功运行。

---

这里的答案对我没有帮助，但在再次检查项目之前，我关闭并打开了 Eclipse（Subversive 是我的 SVN 客户端），问题就消失了。

---

它可能不适用于所有情况，但是当我最近遇到这个问题时，我的“修复”是升级我系统上的 Subversion 包。我一直在运行 1.4.something，当我升级到最新版本（在我的情况下为 1.6.6）时，结帐工作正常。

（我确实尝试重新下载它，但一个干净的目录结帐总是挂在同一个地方。）

---

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

---

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

问题是 case insensitive OS X。检出具有两个同名文件但大小写不同的目录会导致问题。例如，ApproximationTest.java 和 Approximationtest.java 不应位于同一目录中。一旦我们摆脱了其中一个文件，问题就会消失。

---

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

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup、svn revert、svn update 和 svn resolve 均未能成功解决此问题。

我最终解决了如下问题：

在 .svn 目录中查找“sub_dir”

使用 RC -> 属性取消选中条目文件上的“只读”标志

打开条目文件并删除“未完成...”行和相应的校验和

保存并重新启用只读标志

对 my_dir 目录重复

之后，一切都很好。

请注意，我没有任何本地更改，所以我不知道如果你这样做会不会有风险。我没有使用其他人建议的删除/更新方法 - 我通过在 my_dir/sub_dir/sub_sub_dir 目录（以相同的症状开始）上尝试进入这种状态 - 所以我不想冒险让事情变得更糟再次！

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

---

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

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

---

我通过将一些同事的 .svn 目录复制到我的目录中然后更新我的工作副本来解决了这个问题。这是一个不错、快速且干净的解决方案。

---

在面临类似问题时，存储库同步视图中的手动合并有助于解决该问题。

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

---