Question

在克隆mercurial存储库的同时在Windows中获得蓝屏。

重新启动后，我现在收到几乎所有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!

谷歌没有帮助。

任何提示？

Answer 1

当“等待锁定存储库”时，删除存储库文件：.hg/wlock（或者它可能位于.hg/store/lock）

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

Answer 2

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

Answer 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]

在此之后，流产的拉动成功了。

锁已经在两年多前通过局域网上不再存在的机器上的进程设置了。对hg开发人员感到羞耻a）没有充分记录锁; b）当它们变得陈旧时，不要将它们加时间戳以便自动删除。

Answer 4

Coworker在尝试推动BSoD之后，今天遇到了这个问题。他不得不：

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

然后他的回购又恢复了工作。

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

Answer 5

我非常熟悉Mercurial的锁定代码（截至1.9.1）。上述建议很好，但我补充说：

我在野外见过这种情况，但很少，只在Windows机器上看到过。
删除锁定文件是最简单的修复方法，但您必须确保没有其他内容正在访问存储库。（如果锁是一串零，这几乎肯定是正确的。）

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

Answer 6

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

.hg /存储/ phaseroots
.hg / wlock

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

Answer 7

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

今天我得到了＃34;等待锁定存储库＆＃34;在hg push命令上。

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

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

当我去推动目标时，执行hg pull，没问题。

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

事实证明，两个工作区，让他们称之为A和B，有符号链接共享的.hg树：

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

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

Answer 8

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

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

Answer 9

我在尝试推送时在Mac OS X 10.7.5和Mercurial 2.6.2上遇到此问题。升级到Mercurial 3.2.1后，我得到了＃34;没有发现任何变化＆＃34;而不是＆＃34;等待锁定存储库＆＃34;。我发现默认路径已经设置为指向同一个存储库，所以Mercurial会感到困惑并不太令人惊讶。

Answer 10

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

Answer 11

我有同样的问题。我尝试提交时收到以下消息：等待锁定“”持有的工作目录

hg debuglock显示如下：锁：免费 wlock：（66722s）

所以我执行了以下命令，从而为我解决了这个问题：汞调试锁-W

使用Win7和TortoizeHg 4.8.7。

Mercurial坚持“等待锁定”

11 个答案: