SVN 中的工作副本 XXX 被锁定并且清理失败

Posted 2023-02-19

【中文标题】SVN 中的工作副本 XXX 被锁定并且清理失败

【英文标题】：Working copy XXX locked and cleanup failed in SVN

【发布时间】：2010-09-12 18:41:01

【问题描述】：

我在执行svn update 时收到此错误：

工作副本 XXXXXXXX 已锁定，请 执行“清理”命令

当我运行清理时，我得到

清理未能处理 以下路径：XXXXXXXX

如何摆脱这个循环？

【问题讨论】：

我也收到了这条消息。提供的答案看起来有点乏味（尤其是投票最高的答案）。我刚刚关闭了 VS 并重新启动了解决方案，我能够检查一切都很好。

在 eakkas 评论之后使用 Firefox 的 SQLLite 管理器从 WORK_QUEUE 表中删除条目为我解决了这个问题。

有一个简单的答案，只需选中“break locks”选项即可清理您的工作副本

我什至没有获得断锁选项

【参考方案1】：

一种方法是：

将已编辑的项目复制到另一个位置。 删除包含问题路径的文件夹。 通过 Subversion 更新包含文件夹。 根据需要复制文件或合并更改。 提交

另一种选择是删除***文件夹并再次签出。但希望它不会变成那样。

【讨论】：

+1 为您提供此解决方法，不仅可以解决 OP 的问题（和我的问题），还可以提供似乎可以解决任何 svn 问题的 5 个步骤。 -1 以颠覆所需的此类解决方法。

虽然这在技术上可行，但与移除锁相比，这是一种糟糕的方法，值得一票否决。

我无法执行第 3 步，因为...“工作副本已被锁定”

考虑 BradS 的建议“对我来说，诀窍是在我的工作副本顶部运行'svn cleanup'，而不是在问题出现之前我一直在工作的文件夹中发生了。”

对于那些使用 Tortoise SVN 的用户，您可以在签出目录的根文件夹上运行 clean up 并强制 Break Locks。此外，您可以要求它删除未版本控制的文件。然后进行更新。

【参考方案2】：

对我来说，诀窍是在我的工作副本顶部运行svn cleanup，而不是在问题发生之前我一直在工作的文件夹中。

【讨论】：

通常可以，但现在不行了，不知道是不是因为我升级到了SVN 1.7

这对我来说适用于运行 1.7 的客户端，尽管服务器仍然是 1.6.x

非常感谢在 1.7 上为我工作

我已将 Intu 答案中的提示与此提示相结合：查找在其 .svn 文件夹中具有“锁定”文件的父文件夹，然后在那里运行“svn cleanup”。这对我有用。

这对我有用，比 Chuck 的方式快得多。所以值得一试。

【参考方案3】：

查看您的.svn 文件夹，其中将有一个名为lock 的文件。删除该文件，您将能够更新。每个子目录的.svn目录下可能会有更多的锁文件。他们也需要删除。这可以很简单地从命令行以批处理的形式完成，例如

find . -name 'lock' -exec rm -v  \;

请注意，您正在手动编辑 .svn 文件夹中的文件。他们被放在那里是有原因的。这个原因可能是一个错误，但如果不是这样，您可能会损坏您的本地副本。

来源：http://www.svnforum.org/2017/viewtopic.php?p=6068

【讨论】：

+1 我认为这比目前投票率最高的答案要好得多——我讨厌必须先将文件复制到其他地方才能解决这个（常见的！）问题。我的问题是由一个代码生成工具生成的文件与其他人已经添加到 SVN 的同名文件引起的。我想我不首先“svn up”是不好的......

这不再适用于 Tortoise/SVN 1.7（或者至少我找不到任何锁定文件，因为现在有一个带有元数据的集中式数据库）。

这是一个快速的单行代码，它应该递归地删除从当前目录开始的所有锁：find . | grep ".svn/lock" | xargs rm

使用 SVN 1.7，@BradS 的回答似乎更有效。这个答案对我不起作用，而 BradS 对我有用。

就我而言，在任何地方都找不到锁定文件。

【参考方案4】：

在我的情况下，我通过手动删除 WC_LOCK 表中的 SQLite ".svn\wc" 文件锁定记录中的记录来解决它。

我用 SQLite 编辑器打开了“WC”文件并执行了

delete from WC_LOCK

根据eakkas 的评论，您可能还需要删除WORK_QUEUE 表中的所有条目。

【讨论】：

这适用于 Windows 上的 Subversion 1.7.5。从此处下载 SQLite Expert 试用版：sqliteexpert.com/download.html。在 SQL 选项卡中运行上面的“删除”sql 语句。

这样好多了，唯一不同的是我点击了红色（-）按钮

免费的 DI SQL Spy 也可以解决问题：yunqa.de/delphi/doku.php/products/sqlitespy/index

这对我也有用，但我还需要清除 WORK_QUEUE 表中的条目

没有通过从 WC_LOCK 中删除项目来工作 - 工作是查看我的 WORK_QUEUE 项目的 blob 内容，果然是问题文件 - 我从 repo 浏览器中删除了该文件并然后删除了 work_queue 项目 - 在此之后运行清理并恢复业务！

【参考方案5】：

最简单的方法：

转到项目的父目录（文件夹）。 按下右键 按下 TortoiseSVN 然后按下 清理... 清理对话框会自动出现 选择Clean up working copy status、Break locks、Fix time stamps、Vacuum pristine copies、Refresh shell overlays、Include externals 按确定

你成功地完成了你的工作。

查看屏幕截图以供参考。

第一步：

第二步： 启用中断锁定选项（清理弹出窗口中的第二个复选框）

希望这对您有很大帮助。

【讨论】：

在我的情况下，“Break lock”选项就足够了，也许只能先试试这个

好答案。我有一个“对话失明”的案例，从未检查过清理选项。从历史上看，“导航到根目录并清理”曾经有效，但我想在我的情况下打破锁就足够了..

也为我工作！

没想到'break locks'会这样做，因为我没有做任何锁。但显然它打破了导致这个问题的 svn 内部锁。谢谢！

【参考方案6】：

一个同事在工作中经常看到这个消息，对他来说是因为他删除了一个SVN版本控制下的目录没有从SVN中删除它，然后在它的位置创建了一个新目录而不是版本下控件，同名。

如果这是你的问题...：

有不同的方法来修复它，具体取决于目录被替换的方式/原因。

无论哪种方式，您都可能需要：

A) 将现有目录重命名为临时名称

B) 执行 SVN 还原以恢复从文件系统中删除的目录，而不是从 SVN 中删除的目录

从那里，你要么

A) 将相关文件复制到被删除的目录中

B) 如果目录中的内容发生重大变化，请对原始目录执行 SVN 删除，提交并将新目录重命名为所需名称，然后添加 SVN 以获取 that 一个受版本控制。

【讨论】：

您的第二步 B) 对我来说似乎是一个非常糟糕的主意，因为它会破坏保留在新版本中的原始目录项目的修订历史记录。

当这个人从文件系统中删除了一个版本控制的目录而不是从 SVN 中时，发生了非常糟糕的事情。上面的答案可能不是一个完美的恢复，但它是一个恢复。

【参考方案7】：

对我来说，上述解决方案均无效。 我通过打破锁找到了解决方案。 当我执行 svn cleanup 时，我选择了“Break Locks”和“Clean up working copy status”。

【讨论】：

对我来说，打破 Tortoise SVN repo 浏览器的锁定是有效的。打破对签出文件夹的锁定没有任何作用。

【参考方案8】：

这个对我有用。

转到根文件夹， 右键清理 检查所有可用选项 按确定

清理后，您可以更新到最新版本。

【讨论】：

这也适用于我。您需要检查所有可用选项（我的版本中有 6 个条目）才能继续清理；如果您只检查 [Clean up working copy status] 和 [Include externals] 选项，它会失败。

这对我来说完全有效......只需右键单击项目 > 团队 > 清理。不必从 .svn 中的 SQL 或其他任何内容中删除任何行。就这样完成了工作。谢谢！

这在 TortoiseSVN 版本 1.7.4 中也适用于我。我选择了显示的默认复选框。

今天帮助了我，但我不需要检查所有可用选项。最后三个恢复我的更改我没有检查，但它仍然有效。另见***.com/a/35192644/460775

这对我有用。我刚刚检查了Clean up working copy status 和Breaks locks 和Include externals

【参考方案9】：

对我来说，这实际上是乌龟的错，有点。乌龟只是抱怨“无法清理，运行清理”，但是当我运行命令行（svn cleanup）时，它清楚地告诉我它无法删除一些正在使用的文件，解决方案很明显。关闭 Visual Studio（保持文件打开）后，清理工作正常。

其他程序也可以在 repo 中保持文件打开，从而导致此问题。 Excel 保持打开 xls 在另一个实例中是罪魁祸首，因此关闭所有可能使用 repo 中任何内容的程序甚至重新启动以强制程序关闭然后再次尝试清理可能是明智的。

【参考方案10】：

我遇到了这个问题，因为外部文件夹不想链接到现有文件夹。如果在目标是现有（版本化或非版本化）文件夹的位置添加 svn:externals 属性行，您将收到 SVN Woring Copy locked 错误。在这里清理也会告诉你一切都很好，但仍然无法更新。

解决方案：从存储库中删除有问题的文件夹，并在设置了 svn:externals 属性的根文件夹中进行更新。这将创建文件夹，一切都会再次正常。

这个问题对我来说是因为 svn:externals 文件需要目标文件夹进行版本控制。在我注意到这在不同的存储库中不起作用后，我从外部文件交换到外部文件夹并陷入了这个混乱。

【参考方案11】：

最简单的方法是显示隐藏文件夹，然后打开 .SVN 文件夹。您应该会看到一个名为“lock”的零 KB 文件，删除它会解决问题

【参考方案12】：

我在使用 SVN 1.7 时遇到了完全相同的问题，但上面提到的修复都没有奏效。

首先，请确保备份所有已编辑的内容。

花了几个小时后（没有重新下载所有内容，因为我的分支大小超过 6gb），我发现分支的 .svn 文件夹中有一个名为“wc”的 db 文件。

使用任何 db 管理器（我使用 firefox 的 sqlite manager 插件）打开 db 文件并导航到 WC_LOCK 表。该表将包含已获取锁的条目。从表中删除记录，你就完成了:)

【讨论】：

尽管它与上一个答案几乎是重复的，但我还是给了你一票，因为你提到了 firefox SQLite 管理器插件。

【参考方案13】：

当我遇到这个问题时，我发现直接在问题路径上运行清理命令通常似乎有效。然后我将再次从工作根目录运行清理，它会抱怨其他一些目录。我只是重复，直到它停止抱怨为止。

【讨论】：

我无法像以前的答案那样找到锁定文件，但这对我有用:)

【参考方案14】：

如果您在 Windows 机器上，通过浏览器查看存储库，您可能会看到两个文件名相同但大小写不同的文件。 Subversion 区分大小写，而 Windows 不区分大小写，因此当 Windows 认为它​​正在拉下同一个文件而 Subversion 没有时，您可以获得锁定。删除存储库中重复的文件名，然后重试。

【参考方案15】：

我只是创建了一个新文件夹，签出项目，将更新的文件复制到新文件夹中。

它已通过全新结帐修复。

【讨论】：

我也是这样做的。 （我把根本原因归结为 AnkhSVN 弄乱了我的工作副本。AnkhSVN 现在已卸载）。

【参考方案16】：

您是否正在使用 TortoiseSVN 并且刚刚升级？我之前从 1.4 移动到 1.5 并且没有重新启动时遇到过这个问题。 （尝试重新启动）。

您需要重新启动的原因是因为缓存文件变得很时髦。

否则，继续前进，将该工作副本导出到新文件夹（不要复制 .svn 隐藏文件夹），重新签出项目，然后将所有代码移回，然后继续提交。

【讨论】：

我也遇到过这种情况，就是需要重启

【参考方案17】：

只需删除 .svn 文件夹，然后对父目录运行清理。完美运行！

【讨论】：

在 SVN 1.7 中，这不起作用，因为顶部只有一个 .svn 文件夹。如果删除，存储库的附件将被删除。

【参考方案18】：

在 Mac OS 下的版本中： 操作 -> 清理工作副本锁定在...

【参考方案19】：

我经常遇到这样的问题。我的模式导致清理问题。

我在查看器中打开图像文件。 我删除图像文件/文件夹。 我正在尝试提交/更新

关闭打开已删除文件的图像查看器可以解决问题。 也许其他软件可以以同样的方式阻止清理。

一般。我相信在这种情况下重新启动计算机可能会有所帮助。

【参考方案20】：

SVN 通常会在从存储库中获取实际文件之前更新其文件夹中文件的内部结构 (.svn/prop-base)。一旦文件被提取，这将被清除。由于“更新”失败或在更新过程中过早取消，经常会引发错误。

检查 .svn/prop-base 目录下列出的所有文件 删除不在文件夹下的所有文件 清理 更新

现在更新应该可以工作了。

【参考方案21】：

遇到了同样的问题，因为我在受版本控制的文件夹下导出了一个文件夹。不得不从 TortoiseSVN 中删除该文件夹，然后从文件系统中删除该文件夹（TortoiseSVN 不喜欢未版本控制的子文件夹......为什么不呢？？？）

【讨论】：

我应该补充一点，我将一个文件夹导出到同一个文件夹..这就是你解压前一个的方式。版本化文件夹。

【参考方案22】：

我在 TortoiseSVN 下有这个，错误与我在新项目下创建的新目录有关。我刚刚创建了这个项目，所以这个目录以前不可能存在。我查看了存储库浏览器，新文件夹确实已经在存储库中，但是 TortoiseSVN 并没有将其显示为已提交。

为了绕过它，因为我刚刚创建了文件夹，所以我在存储库中删除了它，然后进行了提交。效果很好。

由于我是在 Visual Studio 之外执行此操作的，因此我必须重新启动 Visual Studio 才能再次解决所有问题。

【参考方案23】：

开始搜索....锁定...选择所有列出的文件并删除..已修复

【参考方案24】：

以下应该做：

svn 状态 | grep ".l" | sed 's/.* (.*)$/\1/' | awk '打印长度($1),$1' |排序-nr | awk 'print "pushd" $2"; svn cleanup ; popd"' |嘘

【参考方案25】：

不要删除您的解决方案！

在 .svn 文件夹中有一个名为 lock 的文件，长度为 0 字节

您可以从解决方案中的所有 .svn 文件夹中删除所有这些文件，它会起作用

它在我的情况下有效

【讨论】：

这是最简单的解决方案！为我工作

是的，很遗憾它不适用于最新版本的 SVN。对于最新版本，您必须将其删除，因为不再有锁定文件。似乎不再有任何文件有一个完整的其他文件夹结构。如果有人知道是否还有任何可以以类似于上述方式进行修改的内容，请与我们分享。

【参考方案26】：

文件的就地取消版本化，并重新签出到同一位置，为我解决了这个问题。

在 TortoiseSVN 中，要进行就地取消版本化，请将工作副本的根文件夹从文件列表中右键拖动到目录树中的自身上，然后从弹出菜单中选择“SVN Export versioned items here” . TortoiseSVN 注意到目标与源相同，并建议取消工作副本的版本。

取消版本化后，重新签出到同一文件夹（其中现在包含您拥有的所有文件的未版本化副本）。 TortoiseSVN 会警告您正在签出到现有文件夹，但您可以继续。

此后，清理、更新和其他操作顺利进行。由于上述两个步骤都保留了本地修改，因此不会丢失任何信息（但在此之前备份工作副本可能是个好主意）。

一个警告：如果工作副本包含混合版本或未提交的属性更改，则该信息将丢失。对我来说，这并不常见，考虑到工作副本损坏或丢失未提交的属性更改的选择，我倾向于选择后者。

【参考方案27】：

我在“清理”工作时遇到了这个问题，但“更新”会继续失败。有效的解决方案是通过 Windows 资源管理器删除有问题的文件夹，而不是 TortoiseSVN 的删除（这将删除标记为提交到存储库的内容，然后我进行了“签出”以从存储库中“更新”文件夹。

更多关于 O/S 删除和 SVN 删除的区别的信息在这里： http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

值得注意的是：

当您 TortoiseSVN → 删除一个文件时，它会立即从您的工作副本中删除，并在下次提交时在存储库中标记为删除。

还有：

如果通过资源管理器而不是使用 TortoiseSVN 上下文菜单删除文件，则提交对话框会显示这些文件，并允许您在提交之前将它们从版本控制中删除。但是，如果您更新工作副本，Subversion 会发现丢失的文件并将其替换为存储库中的最新版本。

【参考方案28】：

如果你在 Linux 上，试试这个：

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

然后在该目录上运行cleanup 命令，然后尝试更新。

【参考方案29】：

我执行了以下操作来解决我的问题：

通过在文件夹前面放置一个“_”来重命名有问题的文件夹 文件夹名称。 对父文件夹进行了“清理”。 将有问题的文件夹重命名为原来的名称。 提交了。

【参考方案30】：

在解决方案资源管理器中，右键单击项目，在打开的子菜单中单击颠覆并选择清理。它将解决问题，就像对我一样。希望它会起作用。