在克隆mercurial存储库时,在窗口中出现蓝屏。

重启后,我现在得到这条消息几乎所有的hg命令:

c:\src\>hg commit
waiting for lock on repository c:\src\McVrsServer held by '\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
interrupted!

谷歌没有帮助。

任何建议吗?


当“waiting for lock on repository”时,删除存储库文件:.hg/wlock(或者它可能在.hg/store/lock中)

在删除锁文件时,必须确保没有其他任何东西正在访问存储库。(如果锁是一个0或空白的字符串,这几乎肯定是正确的)。


如果锁定的回购是原始的,我无法想象它是修改它来克隆它,所以它只是阻止你在中间修改它,把克隆搞砸。开锁后应该没问题。

但是,新的克隆副本(如果它是本地克隆)可能处于任何形式的畸形状态,因此您应该将其丢弃并重新开始。(如果它是一个远程克隆,我希望它失败了,并且已经扔掉了不完整的副本。)


当工作目录等待锁定时,删除.hg/wlock。


我非常熟悉Mercurial的锁定代码(从1.9.1开始)。上面的建议很好,但我想补充一点:

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

(好奇的人:我还没能找到这个问题的原因,但怀疑这可能是旧版本的Mercurial访问存储库,或者在某些版本的Windows上Python的socket.gethostname()调用中出现问题。)


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


同事今天也遇到了同样的问题,在试图推的时候,他突然晕眩了。他不得不:

删除文件.hg/store/lock(根据接受的答案) 删除文件。hg/store/phaseroots(根据这个TortoiseHG错误报告)

然后他的回购又起作用了。

编辑:根据@Marmoute的评论,在处理与锁相关的问题时,使用hg debuglock比盲目删除.hg/store/lock文件更安全。


我不指望这是一个成功的答案,但这是一个相当不寻常的情况。 以防我以外的人碰到。

今天我在hg push命令中得到了“waiting for lock on repository”。

当我杀死hung hg命令时,我看不到。hg/store/lock

当我在挂起命令时寻找.hg/store/lock时,它是存在的。但是当hg命令被杀死时,锁文件被删除了。

当我走到目标推,并执行hg拉,没有问题。

最终我意识到hg推送上的进程ID是锁等待消息每次都在改变。结果是,“hg push”挂起等待一个由它自己持有的锁(或者可能是一个子进程,我没有进一步研究)。

这两个工作区,让我们称它们为A和B,通过symlink共享。hg树:

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

这对Mercurial来说不是一件好事。Mercurial不理解两个工作区共享同一个存储库的概念。然而,我确实理解,从另一个VCS来到Mercurial的人可能想要这个(Perforce想要,尽管不是DVCS;据报道,芭莎DVCS可以这样做)。我很惊讶符号链接的REP-ROOT/。Hg完全工作,尽管它似乎除了这个推力。


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


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

.hg /商店/ phaseroots .hg / wlock

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


我遇到的问题是无法检测到锁文件。我在这里找到了解决方案: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]

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

这个锁是在两年多以前由一台不在局域网上的机器上的进程设置的。hg开发者真可耻,因为a)没有充分地记录锁;B)没有在过期后自动删除的时间戳。


我也有同样的问题。当我试图提交时,收到以下消息:

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

Hg debuglock显示:

lock:  free
wlock:  (66722s)

所以我执行了以下命令,这为我解决了问题:

hg debuglocks -W

使用Win7和TortoiseHg 4.8.7。