logo标签列表

Mercurial卡在“等待锁定”状态

mercurial
361

在克隆Mercurial存储库时，在Windows中遇到蓝屏错误。

重启后，现在我执行几乎所有的hg命令都会得到以下消息：

c:\src\>hg commit
等待锁定c:\src\McVrsServer存储库，由'\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
中断！

谷歌没有帮助。

有什么提示吗？

3
哇，我提交时也遇到了蓝屏并得到了相同的错误。很高兴不是只有我一个人这样！ - FiniteLooper
3
我提议在http://bz.selenic.com/show_bug.cgi?id=4752上改进错误信息反馈。 - Kalle Richter
11个回答
509

当出现“等待仓库锁定”时，请删除存储库文件：.hg/wlock （或者可能在 .hg/store/lock 中）。

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

103
我的问题与克隆或蓝屏无关，而是因为我删除了.hg/wlock文件以清除锁定。 - frank hadder
32
在出现锁定故障的情况下，应运行hg recover命令。 - James Broadhead
9
非常感谢 - 在删除了.hg/wlock之后，我不知道问题出在哪里。 - Andrew Buss
34
在我的情况下（使用TortoiseHg V2.9.2和Mercurial 2.7.2），文件名为"wlock"而不是"lock"；它位于".hg"目录中，而不是".hg/store"。 - Fernando
7
每当要进行更改时，@Marmoute存储库都会被锁定。如果某些原因导致该过程失败--例如Mercurial中的错误、机器故障等--则锁定文件将保留不清理。我认为在此建议手动删除锁定文件是为了解决那些存储库以某种方式处于“未清理”状态的情况。称其为“盲目删除mercurial保护”并不是一个公平也不准确的描述这些情况的行为。 - JoGusto
显示剩余9条评论
350

当 等待工作目录上的锁时，删除 .hg/wlock 文件。

6
这对我来说也是一样的情况。这是一个指向当前 server:pid 的'nix上的符号链接。非常感谢。然后我必须运行 $ hg recover 来清除我因为按下 ctrl+c 而中断的现有日志和提交消息。不确定，但您可以尝试运行 $ hg recover 而不删除锁定文件，它可能会为您完成。值得一试，我想。 - sholsinger
2
只是一个提醒给@sholsinger，运行hg recover不起作用，除非您先删除锁定。我试过了。 - Dan
1
仓库被锁定是有原因的，可能是另一个进程正在操作该仓库。你应该找到该进程并终止它，而不是盲目地移除mercurial保护。仅仅删除文件可能会导致仓库损坏。 - Marmoute
@Marmoute 在我的情况下，我不得不删除锁定，因为没有其他进程在使用该仓库。但是我同意，首先应该寻找另一个进程。 - Mi-La
在尝试拉取时，我突然收到了这条消息，在几天的推拉中没有出现任何问题。删除文件后问题得到解决。该文件大小为0 KB，这意味着它可能是空的。直接删除文件是否可以？我猜它对保护有用。 - Ben Carp
48

我曾遇到过没有检测到锁文件的问题。我在这里找到了解决方案：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）没有为它们设置时间戳以在它们过期时自动删除它们。

23
小窍门：如果锁定的是wlock，则使用hg debuglocks --force-wlock。 - Brad Turek
5
我使用Tortoise Hg已经七年多了。直到大约三个月前我才发现这个问题。在过去的三个月中，我已经看到了三次。一些更新必须加剧了这个问题。 - d ei
大家好，我的两个锁都显示为 “free”，但是我还是得到了“等待锁定 \uGames/MyGameRepo 工作目录由进程 '24012' 在主机 MyHost 上持有”的消息。尝试推送很长时间后，提示“中止：\uGames/MyGameRepo 工作目录超时等待由 MyHost:24012 持有的锁定”。我无法推送任何东西...我该如何解决这个问题呢？ - Reem Al-Assaf
21
同事今天在推送时遇到了完全相同的问题，在出现蓝屏死机的情况下。他必须要： 然后他的存储库就可以工作了。
编辑：根据@Marmoute的评论 - 处理锁相关问题时，使用hg debuglock是一个比盲目删除.hg/store/lock文件更安全的替代方法。
2
  1. 没有任何理由让你去触碰phaseroots文件，它与锁定完全无关。
  2. 盲目地删除wlock是一个坏主意，很可能有另一个进程在使用它。使用hg debuglock来找出发生了什么，并终止持有锁的进程。
 - Marmoute
4
  1. 鉴于移除后问题得到了解决，我必须不同意。
  2. 当时不知道有 hg debuglock（也找不到任何文档），由于系统刚刚从重启中恢复，显然没有锁定存储库 - 因此删除锁定文件是适当的。
 - Ian Kemp
12

我非常熟悉Mercurial的锁定代码（截至1.9.1版本）。以上建议很好，但我要补充一点：

  1. 我曾经在使用Windows机器时遇到过这种情况，但很少见。
  2. 删除锁定文件是最简单的解决方法，但您必须确保没有其他内容正在访问该存储库。（如果锁定是由多个零组成的字符串，则几乎肯定如此）。

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

3
就我个人而言，在Ubuntu上也遇到了这个问题。我已经好几周没用软件仓库了，所以不记得是什么原因导致它处于那种状态。 - Cosmologicon
9

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

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上也遇到了同样的问题。

解决办法是删除以下文件:

  1. .hg/store/phaseroots
  2. .hg/wlock

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

欢迎来到Stackoverflow。尝试为帖子添加更多内容。 - Nagama Inamdar
5
  1. 没有任何理由需要触碰phaseroots文件，它与锁定完全无关。
  2. 盲目删除wlock是一个不好的主意，很可能有另一个进程在使用它。使用hg debuglock来找出发生了什么，并终止持有锁的进程。
 - Marmoute
6

我并不认为这个答案能赢得胜利，但这是一个相当不寻常的情况。如果有人遇到类似问题，可以提一下。

今天我在执行hg push命令时遇到了“等待锁定存储库”的情况。

当我kill掉hang住的hg命令时，我发现没有.hg/store/lock文件。

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

当我去push的目标处执行hg pull时，没有问题。

最终我意识到，在hg push的进程ID上，锁等待消息每次都在改变。原来，“hg push”在等待由自己（或可能是子进程）持有的锁。

事实证明，两个工作区（称为A和B）共享了符号链接的.hg目录：

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

在Mercurial中，这样做并不是一个好主意。Mercurial无法理解两个工作区共享同一个仓库的概念。然而，我理解从其他版本控制系统转到Mercurial的人可能会希望这样做（Perforce可以，尽管它不是DVCS；据报道Bazaar DVCS也可以）。我很惊讶符号链接的REP-ROOT/.hg能够正常工作，尽管它似乎除了这个push之外都能工作。

Mercurial不会跟踪.hg/中的dirstate吗？当你说这些存储库“工作”时，是否在一个存储库中运行hg up会使另一个存储库的dirstate不同步，或者Mercurial做了一些特殊的支持？ - binki
1
你可以使用共享扩展（与核心Mercurial一起提供）从单个存储库中拥有多个工作目录。 - Marmoute
2

我在尝试推送时遇到了这个问题，我的操作系统是Mac OS X 10.7.5，Mercurial版本是2.6.2。升级到Mercurial 3.2.1后，我得到了“未发现更改”，而不是“等待仓库锁定”。我发现默认路径已经设置为指向相同的仓库，所以Mercurial会感到困惑也就不足为奇了。

1
我发现默认路径不知何故被设置为指向同一代码库。谢谢，我费了很大的力气才解决了这个问题，而path设置是罪魁祸首。 - WoJ
2
如果被锁定的存储库是原始存储库，我想象不出会对其进行修改以克隆它，所以只是防止你在中途更改并搞乱克隆。删除锁定后应该没问题了。
新克隆的副本（如果是本地克隆）可能处于任何格式不正确的状态，因此您应该将其丢弃并重新开始。（如果是远程克隆，我希望它失败并已经扔掉了不完整的副本。）
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接