Mercurial卡在“等待锁定”答案

【问题标题】：Mercurial stuck "waiting for lock"Mercurial卡在“等待锁定”
【发布时间】：2010-09-05 23:40:19
【问题描述】：

在克隆 mercurial 存储库时在 Windows 中出现蓝屏。

重新启动后，我现在几乎所有 hg 命令都会收到此消息：

c:\src\>hg 提交等待 '\x00\x00\x00\x00\x00\ 持有的存储库 c:\src\McVrsServer 的锁定 x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' 打断了！

Google 帮不上忙。

有什么建议吗？

【问题讨论】：

哇，我在提交时也出现了蓝屏并得到了同样的错误。很高兴我不是唯一一个！
我在bz.selenic.com/show_bug.cgi?id=4752提出了更好的错误信息反馈

标签： mercurial

【解决方案1】：

当“等待锁定仓库”时，删除仓库文件：.hg/wlock（也可能在.hg/store/lock）

删除锁定文件时，您必须确保没有其他任何东西正在访问存储库。（如果锁是一串零或空白，这几乎肯定是真的）。

【讨论】：

我的问题与克隆或蓝屏无关，但对我来说，我删除了 .hg/wlock 文件以清除锁定。
hg recover 应该在锁定失败后运行。
非常感谢 - 删除 .hg/wlock 后我不知道问题出在哪里
在我的例子中（TortoiseHg V2.9.2 with Mercurial 2.7.2），文件名是“wlock”而不是“lock”；它被放置在“.hg”目录中，而不是“.hg/store”中。
@Marmoute -- 每当要进行更改时，存储库就会被锁定。如果某些事情导致该进程失败——即，Mercurial 中的错误、机器停机等——锁定文件仍然存在，没有被清除。我相信这里手动删除锁定文件的建议是为了解决存储库以某种方式处于“不干净”状态的情况。将其称为“盲目地取消 mercurial protection”既不公平也不准确地描述了这些案例中发生的情况。

【解决方案2】：

当waiting for lock on working directory时，删除.hg/wlock。

【讨论】：

这就是我的情况。这是 'nix 上与当前 server:pid 的符号链接。谢谢一堆。然后我必须运行$ hg recover 来清除我ctrl+c'ed 的现有日志（和提交消息）。不确定，但您可以在不删除锁定文件的情况下运行$ hg recover，它会为您执行此操作。我想值得一试。
只是给@sholsinger 的注释，说除非您先删除锁定，否则运行 hg recover 不起作用。我试过了。
存储库因某种原因被锁定，另一个进程正在处理该存储库。您应该找到该进程并终止它，而不是盲目地删除 mercurial 保护。仅删除文件可能会导致存储库损坏。
@Marmoute 在我的情况下，我不得不移除锁，因为没有其他进程正在处理 repo。但我同意，值得先寻找另一个流程
我在尝试拉的时候突然收到这个消息，在拉和推了几天之后没有问题。删除文件后问题解决。该文件为 0 KB，这意味着我猜它是空的。简单地删除文件就可以了吗？我想这对保护很有用。

【解决方案3】：

我遇到了这个问题，没有可检测到的锁定文件。我在这里找到了解决方案：http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

这是来自 Tortoise Hg Workbench 控制台的记录

% hg debuglocks
lock:  user None, process 7168, host HPv32 (114213199s)
wlock: free
[command returned code 1 Sat Jan 07 18:00:18 2017]
% hg debuglocks --force-lock
[command completed successfully Sat Jan 07 18:03:15 2017]
cmdserver: Process crashed
PaniniDev% hg debuglocks
% hg debuglocks
lock:  free
wlock: free
[command completed successfully Sat Jan 07 18:03:30 2017]

在此之后，中止的拉取成功运行。

锁定已在 2 年多前由不再位于 LAN 上的计算机上的进程设置。 hg 开发人员感到羞耻 a) 没有充分记录锁； b) 当它们变得陈旧时，不给它们加时间戳以便自动删除。

【讨论】：

Protip：如果wlock是被锁定的，使用hg debuglocks --force-wlock
我使用乌龟汞已有 7 年多了。直到大约 3 个月前，我才发现这个问题。在过去的 3 个月里，我已经看过 3 次了。某些更新一定加剧了这个问题。
伙计们，我的两个锁都显示free，但我得到了waiting for lock on working directory of \\uGames/MyGameRepo held by process '24012' on host MyHost。推了半天，abort: working directory of \\uGames/MyGameRepo: timed out waiting for lock held by MyHost:24012。我无法推送任何东西...我该如何解决这个问题？

【解决方案4】：

同事今天遇到了这个确切的问题，在尝试推动时出现了 BSoD。他必须：

删除文件.hg/store/lock（根据the accepted answer）
删除文件.hg/store/phaseroots（按照this TortoiseHG bug report）

然后他的回购再次工作。

编辑：根据@Marmoute 的评论-在处理与锁定相关的问题时，使用hg debuglock 是一种更安全的替代方法，而不是盲目地删除.hg/store/lock 文件。

【讨论】：

1) 绝对没有理由触碰 phaseroots 文件，它与锁定完全无关。 2）盲目删除 wlock 是一个坏主意，可能有另一个进程在使用它。使用 hg debuglock 找出它发生了什么并终止持有锁的进程
1) 考虑到删除它可以解决问题，我不得不不同意。 2）当时不知道 hg debuglock （也找不到任何文档），并且由于系统刚刚重新启动，因此显然没有锁定存储库 - 因此删除锁定文件是合适的。

【解决方案5】：

我非常熟悉 Mercurial 的锁定代码（从 1.9.1 开始）。上面的建议很好，但我要补充一点：

我在野外见过这种情况，但很少见，而且只在 Windows 机器上见过。
删除锁定文件是最简单的解决方法，但您必须确保没有其他任何东西正在访问存储库。（如果锁是一串零，这几乎肯定是真的）。

（出于好奇：我还没有找到这个问题的原因，但怀疑是旧版本的 Mercurial 访问存储库或 Python 的 socket.gethostname() 调用某些版本的问题窗户。）

【讨论】：

FWIW 它只是在 Ubuntu 上发生在我身上。这是我几周以来第一次使用该存储库，所以我不记得是什么让它处于那种状态。

【解决方案6】：

我遇到了同样的问题。当我尝试提交时收到以下消息：

waiting for lock on working directory of <MyProject> held by '...'

hg debuglock 显示了这个：

lock:  free
wlock:  (66722s)

所以我执行了以下命令，这为我解决了问题：

hg debuglocks -W

使用 Win7 和 TortoiseHg 4.8.7。

【讨论】：

【解决方案7】：

我在 Win 7 上遇到了同样的问题。解决方案是删除以下文件：

.hg/store/phaseroots
.hg/wlock

至于 .hg/store/lock - 没有这样的文件。

【讨论】：

欢迎来到 Stackoverflow。尝试在帖子中添加更多内容
1) 绝对没有理由触碰 phaseroots 文件，它与锁定完全无关。 2）盲目删除 wlock 是一个坏主意，可能有另一个进程在使用它。使用hg debuglock 找出它发生了什么并终止持有锁的进程。

【解决方案8】：

我不认为这是一个成功的答案，但这是一个相当不寻常的情况。提及以防我以外的人遇到它。

今天我在 hg push 命令上收到“等待锁定存储库”。

当我终止挂起的 hg 命令时，我看不到 .hg/store/lock

当我在命令挂起时查找 .hg/store/lock 时，它存在。但是当 hg 命令被杀死时，lockfile 被删除了。

当我走到push的目标，执行hg pull，没问题。

最终我意识到 hg push 上的进程 ID 是锁等待消息每次都在变化。事实证明，“hg push”正在等待自己持有的锁（或者可能是一个子进程，我没有进一步调查）。

事实证明，这两个工作区，我们称它们为 A 和 B，具有由符号链接共享的 .hg 树：

A/.hg --symlinked-to--> B/.hg

这对 Mercurial 来说不是一件好事。 Mercurial 不理解两个工作区共享同一个存储库的概念。但是，我确实理解从另一个 VCS 来到 Mercurial 的人可能想要这个（Perforce 确实如此，尽管不是 DVCS；据报道 Bazaar DVCS 可以这样做）。我很惊讶符号链接的 REP-ROOT/.hg 完全有效，尽管它似乎除了这次推送。

【讨论】：

不 hg 跟踪 .hg/ 中的目录状态吗？当您说存储库“工作”时，不会在一个中运行 hg up 会使另一个中的 dirstate 不同步 - 还是 mercurial 做了一些特殊的事情来支持这一点？
您可以使用共享扩展（Core Mercurial 附带）从一个存储库中拥有多个工作目录。

【解决方案9】：

如果锁定的 repo 是原始的，我无法想象它是修改它来克隆它，所以它只是阻止你在中间更改它并弄乱克隆。解开锁应该没问题。

但是，新的克隆副本（如果它是本地克隆）可能处于任何格式错误的状态，因此您应该将其丢弃并重新开始。（如果是远程克隆，我希望它失败并且已经扔掉了不完整的副本。）

【讨论】：

【解决方案10】：

我在 Mac OS X 10.7.5 和 Mercurial 2.6.2 上尝试推送时遇到了这个问题。升级到 Mercurial 3.2.1 后，我得到“未找到更改”而不是“等待锁定存储库”。我发现默认路径以某种方式被设置为指向同一个存储库，因此 Mercurial 会感到困惑也就不足为奇了。

【讨论】：

我发现默认路径被设置为指向同一个存储库。这。谢谢，我通过循环来解决问题，path 设置是罪魁祸首。

【解决方案11】：

如果它只发生在映射驱动器上，它可能是错误https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share。使用 UNC 路径而不是驱动器号似乎可以回避这个问题。

【讨论】：