水星陷入“等待锁定”

346

克隆Mercurial存储库时，在Windows中出现了蓝屏。

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

c：\ src \> hg提交
等待锁在存储库c：\ src \ McVrsServer上，由'\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00'
打断！

Google没有帮助。

有小费吗？

mercurial 
— 吉姆
source
3
哇，我在提交时也遇到了蓝屏问题，并得到了相同的错误。很高兴我不是唯一的一个！
— CBarr 2013年
3
— Karl Richter

Answers:

489

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

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

— 吉姆
source
103
我的问题与克隆或BSOD无关，但对我来说，我删除了.hg / wlock文件以清除锁定。
— 坦率的哈德
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中的错误，计算机故障等），则锁文件将保留而不是被清除。我相信这里手动删除锁定文件的建议是为了解决那些以某种方式使存储库处于“不干净”状态的情况。称其为“盲目撤消汞保护”并不是对这些情况正在发生的公正或准确的描述。
— JoGusto
345

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

— 蒂亚戈·马托斯（Tiago Matos）
source
6
对我来说就是这种情况。这是'nix到当前版本的符号链接server:pid。谢谢你 然后，我不得不运行$ hg recover以清除已编辑的现有日志（＆提交消息）ctrl+c。不确定，但是您可以在$ hg recover不删除锁定文件的情况下运行，它将为您完成。我想值得一试。
— sholsinger 2011年
2
对于@sholsinger而言，仅需注意一条便条，即除非先删除锁定，否则运行hg restore不会起作用。我尝试过这个。
— 2013年
1
仓库由于某种原因被锁定，另一个进程正在仓库上工作。您应该找到该过程并终止它，而不是盲目地取消汞保护。仅删除文件可能会导致存储库损坏。
— Marmoute 2015年
@Marmoute在我的情况下，我必须删除锁，因为回购上没有其他进程在工作。但是我同意，值得首先寻找另一个过程
— Mi-La
连续几天没有问题后，尝试拉动时突然收到此消息。删除文件后，问题已解决。该文件的大小为0 KB，这意味着我猜它为空。只需删除文件就可以了吗？我想这对保护很有用。
— 本·卡尔
47

我遇到了没有可检测到的锁定文件的问题。我在这里找到了解决方案：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]

此后，中止的拉力成功运行。

该锁定是在两年前通过不再位于LAN上的计算机上的进程设置的。使hg开发人员感到羞耻的原因是：a）没有充分记录锁；b）当它们过时时，请不要为它们自动添加时间戳记。

— 托马斯·夏普莱斯
source
23
提示：如果wlock是被锁住的人，请使用hg debuglocks --force-wlock
— Brad Turek
5
我已经使用草龟汞超过7年了。直到大约3个月前，我才发现问题。在过去的三个月中，我已经看过3次了。某些更新肯定加剧了该问题。
— d ei
20

今天，在尝试推送的BSoD之后，同事遇到了这个确切的问题。他不得不：

然后他的回购再次起作用。

编辑：根据@Marmoute的评论-处理与锁相关的问题时，使用hg debuglock是一种安全的选择，而不是一味地删除.hg/store/lock文件。

— 伊恩·坎普
source
2
1）绝对没有理由您应该触摸phaseroots文件，这绝对与锁定无关。2）盲目地删除wlock是一个坏主意，可能有另一个进程正在使用它。使用hg debuglock找出发生了什么并终止持有该锁的进程
— Marmoute 2015年
3
1）考虑到删除它可以解决问题，所以我不得不不同意。2）当时不了解hg debuglock（也找不到关于它的任何文档），并且由于系统刚从重新启动启动，因此显然没有锁定存储库的任何操作-因此删除锁定文件是适当的。
— 伊恩·坎普
12

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

  1. 我在野外看到过这种情况，但很少见，仅在Windows计算机上看到过。
  2. 删除锁定文件是最简单的解决方法，但是您必须确保没有其他东西可以访问存储库。（如果锁是一串零，则几乎可以肯定是这样）。

（出于好奇：我尚未能够找到导致此问题的原因，但是怀疑是Mercurial访问存储库的版本过旧，还是某些版本的Windows上Python的socket.gethostname（）调用中存在问题。）

— 布拉德·奥
source
2
FWIW只是在Ubuntu上发生了。这是我几个星期以来第一次使用该存储库，所以我不记得是什么让它处于这种状态。
— Cosmologicon 2014年
7

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

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

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

— 伊万·杜洛夫（Ivan Dulov）
source
欢迎使用Stackoverflow。尝试在帖子中添加更多内容
— NJInamdar
5
1）绝对没有理由您应该触摸phaseroots文件，这绝对与锁定无关。2）盲目地删除wlock是一个坏主意，可能有另一个进程正在使用它。用于hg debuglock确定发生了什么并终止持有锁的进程。
— Marmoute 2015年
6

我不希望这是一个成功的答案，但这是一个非常不寻常的情况。提到万一我以外的人遇到了它。

今天，我在hg push命令上获得了“等待存储库锁定”。

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

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

当我去推的目标，并执行汞拉，没有问题。

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

事实证明，两个工作区（分别称为A和B）具有由symlink共享的.hg树：

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

这与Mercurial无关。Mercurial无法理解共享相同存储库的两个工作区的概念。但是，我确实知道，有人从另一个VCS来到Mercurial可能会想要这样做（Perforce确实做到了，尽管不是DVCS；据报道，Bazaar DVCS可以这样做）。我感到惊讶的是，一个符号链接的REP-ROOT / .hg完全可以工作，尽管除了此推动之外似乎还行。

— 克拉兹·格莱
source
hg不在dirdir .hg/吗？当您说存储库“有效”时，不是hg up在一个仓库中运行该目录库就不会在另一个仓库中使目录目录不同步吗？或者，Mercurial是否做了一些特殊的事情来支持这一工作？
— Binki 2015年
1
您可以使用共享扩展名（Core Mercurial附带）在单个存储库中具有多个工作目录。
— Marmoute 2015年
4

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

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

hg debuglock 显示了这个：

lock:  free
wlock:  (66722s)

因此，我执行了以下命令，从而为我解决了该问题：

hg debuglocks -W

使用Win7和TortoiseHg 4.8.7。

— 用户名
source
2

如果锁定的存储库是原始存储库，那么我无法想象它会对其进行修改以克隆它，因此这只是防止您在中间对其进行更改并弄乱了克隆库。卸下锁后应该没问题。

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

— 市场营销
source
2

尝试推送时，我在Mac OS X 10.7.5和Mercurial 2.6.2上遇到了此问题。升级到Mercurial 3.2.1之后，我得到了“未找到更改”，而不是“等待锁定存储库”。我发现默认路径已经设置为指向同一存储库，因此Mercurial会感到困惑并不奇怪。

— JWWalker
source
1
我发现默认路径已设置为指向同一存储库。这个。谢谢，您-我经过循环来解决问题，而path设置是罪魁祸首。
— WoJ
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.