357

克隆 mercurial 存储库时在 Windows 中出现蓝屏。

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

c:\src\>hg 提交
等待 '\x00\x00\x00\x00\x00\ 持有的存储库 c:\src\McVrsServer 的锁定
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
打断了！

谷歌没有帮助。

有小费吗？

4

11 回答 11

504

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

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

于 2008-08-15T23:20:18.820 回答
350

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

于 2010-06-02T18:39:16.287 回答
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]

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

该锁已在 2 多年前由不再位于 LAN 上的机器上的进程设置。hg 开发人员感到羞耻 a) 没有充分记录锁；b) 当它们变得陈旧时，不给它们加时间戳以便自动删除。

于 2017-01-07T23:16:34.297 回答
20

同事今天遇到了这个确切的问题，在尝试推动时出现了 BSoD。他不得不：

然后他的回购再次工作。

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

于 2013-05-07T15:36:57.763 回答
12

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

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

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

于 2011-11-02T13:36:33.463 回答
8

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

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

hg debuglock显示了这一点：

lock:  free
wlock:  (66722s)

所以我执行了以下命令，这为我解决了问题：

hg debuglocks -W

使用 Win7 和 TortoiseHg 4.8.7。

于 2018-07-24T05:47:15.463 回答
7

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

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

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

于 2015-03-12T09:24:12.107 回答
6

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

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

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

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

当我到达推送的目标，并执行 hg pull 时，没问题。

最终我意识到 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 完全有效，尽管它似乎除了这个推送。

于 2014-08-01T22:22:55.170 回答
2

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

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

于 2008-08-16T20:54:27.880 回答
2

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

于 2014-11-24T18:10:12.287 回答
1

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

于 2012-07-12T05:20:48.943 回答