Mercurial坚持"等待锁定"

删除锁定文件时,必须确保没有其他内容正在访问存储库.(如果锁是一串零,这几乎肯定是正确的).

When waiting for lock on working directory, delete .hg/wlock.

没有可检测到的锁文件,我遇到了这个问题.我在这里找到了解决方案: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年多前通过一个不再在局域网上的机器上的进程设置了.对hg开发人员感到羞耻a)没有充分记录锁; b)当它们变得陈旧时,不要将它们加时间戳以便自动删除.

在尝试推动BSoD之后,今天同事确实遇到了这个问题.他不得不:

删除文件.hg/store/lock(根据接受的答案)

删除文件.hg/store/phaseroots(根据TortoiseHG错误报告)

然后他的回购再次奏效.

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

我对Mercurial的锁定代码非常熟悉(截至1.9.1).上述建议很好,但我补充一点:

我在野外看到过这种情况,但很少见,只能在Windows机器上看到.

删除锁定文件是最简单的修复,但您必须确保没有其他任何内容正在访问存储库.(如果锁是一串零,这几乎肯定是正确的).

(对于好奇:我还没有能够找到这个问题的原因,但怀疑它是访问存储库的旧版本Mercurial或某些版本的Windows上的Python的socket.gethostname()调用问题.)

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

.hg /存储/ phaseroots

.hg/wlock

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

我不认为这是一个成功的答案,但这是一个相当不寻常的情况.提及万一我以外的其他人遇到它.

今天我在hg push命令上得到了"等待锁定存储库".

当我杀死挂起的hg命令时,我看不到.hg/store/lock

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

当我去推动目标,并执行hg拉,没问题.

最终我意识到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可以工作,虽然它似乎除了这个推动.