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

重新启动后,我现在收到几乎所有hg命令的以下消息: Google帮不上忙。

有什么提示吗?

评论

哇,提交时我也出现了蓝屏,并得到了相同的错误。很高兴我不是唯一的一个!

我在bz.selenic.com/show_bug.cgi?id=4752
上提出了错误消息的更好反馈

#1 楼

当“等待锁定存储库”时,删除存储库文件:.hg/wlock(或者它可能位于.hg/store/lock 中)资料库。 (如果锁是零或空白的字符串,则几乎可以肯定是这样)。

评论


我的问题与克隆或BSOD无关,但对我来说,我删除了.hg / wlock文件以清除锁定。

–坦率的哈德
2010-2-28在7:59

hg recovery应该在锁定状态破裂后运行。

–詹姆斯·布罗德黑德
2011年12月8日在16:49



非常感谢-删除.hg / wlock之后,我不知道问题是什么

–安德鲁·巴斯(Andrew Buss)
2012年10月1日,下午1:35

就我而言(TortoiseHg V2.9.2和Mercurial 2.7.2),文件名是“ wlock”而不是“ lock”。并将其放置在“ .hg”目录中,而不是在“ .hg / store”中。

–费尔南多
15年4月24日在19:41

@Marmoute-每当进行更改时,存储库就会被锁定。如果由于某种原因导致该过程失败(例如,Mercurial中的错误,计算机故障等),则锁文件将保留而不是清除。我相信这里手动删除锁定文件的建议是为了解决那些存储库以某种方式处于“不干净”状态的情况。称其为“盲目取消汞保护”并不是对在这些情况下正在发生的事情的公正也不准确的描述。

– JoGusto
16年8月12日在15:14

#2 楼

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

评论


对我来说就是这种情况。这是'nix上到当前服务器的符号链接:pid。谢谢你然后我必须运行$ hg recovery来清除我ctrl + c编写的现有日志(&提交消息)。不确定,但是您可以在不删除锁文件的情况下运行$ hg recovery,它将为您完成。我想值得一试。

–骗子
2011年4月26日0:43



对于@sholsinger而言,仅需注意一条便条,即除非先删除锁定,否则运行hg restore不会起作用。我尝试过这个。

–丹
2013年6月5日18:33

仓库由于某种原因被锁定,另一个进程正在仓库上工作。您应该找到该过程并终止它,而不是盲目地取消汞保护。仅删除文件可能会导致存储库损坏。

– Marmoute
2015年6月25日下午0:43

@Marmoute在我的情况下,我必须删除锁,因为回购上没有其他进程在工作。但我同意,值得先寻找其他程序

– Mi-La
17年4月26日在17:54

连续几天没有问题后,在尝试拉动时突然收到此消息。删除文件后,问题已解决。该文件的大小为0 KB,这意味着我猜它为空。只需删除文件就可以了吗?我想这对保护很有用。

–本鲤鱼
18年1月15日在10:18

#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)当它们过时时,请不要为它们自动添加时间戳记。

评论


Protip:如果wlock是被锁定的那个,请使用hg debuglocks --force-wlock

–布拉德·图瑞克(Brad Turek)
17年9月18日在16:32

我已经使用草龟汞超过7年了。直到大约3个月前,我才发现问题。在过去的三个月中,我已经看过3次了。一些更新肯定加剧了该问题。

– ei
18年2月20日在0:49

#4 楼

今天,在尝试推送的BSoD之后,同事有这个确切的问题。他必须:


删除文件.hg/store/lock(根据公认的答案)
删除文件.hg/store/phaseroots(根据此TortoiseHG错误报告)

然后他的存储库又重新工作了。

评论


1)绝对没有理由您应该触摸phaseroots文件,这绝对与锁定无关。 2)盲目地删除wlock是一个坏主意,可能有另一个进程正在使用它。使用hg debuglock找出发生了什么并终止持有该锁的进程

– Marmoute
2015年6月25日在0:45



1)考虑到删除它可以解决问题,所以我不得不不同意。 2)当时不了解hg debuglock(也找不到关于它的任何文档),并且由于系统刚从重新启动启动,因此显然没有锁定存储库的任何东西-因此删除锁定文件是适当的。

–伊恩·坎普(Ian Kemp)
15年6月25日在7:30

#5 楼

我非常熟悉Mercurial的锁定代码(自1.9.1起)。上面的建议是很好的,但我要补充一点:


我在野外看到过这种情况,但很少见,并且仅在Windows计算机上看到。
删除锁文件是最简单的修复,但是您必须确保没有其他东西可以访问存储库。 (如果锁是一串零,那几乎可以肯定是对的。)。

(出于好奇:我尚未能够找到导致此问题的原因,但怀疑它是较旧版本的Mercurial访问存储库,或在某些Windows版本上Python的socket.gethostname()调用中出现问题。)

评论


FWIW只是在Ubuntu上发生在我身上。这是我几个星期以来第一次使用该存储库,所以我不记得是什么让它处于这种状态。

–Cosmologicon
2014-10-18 14:29

#6 楼

我在Win 7上也遇到了同样的问题。
解决方案是删除以下文件: >
.hg / store / lock-没有此类文件。

评论


欢迎使用Stackoverflow。尝试在帖子中添加更多内容

– NJInamdar
15年3月12日在9:33

1)绝对没有理由您应该触摸phaseroots文件,这绝对与锁定无关。 2)盲目地删除wlock是一个坏主意,可能有另一个进程正在使用它。使用hg debuglock找出发生了什么并终止持有该锁的进程。

– Marmoute
15年6月25日,0:41

#7 楼

我不希望这会是一个成功的答案,但这是一个非常不寻常的情况。
提到我以外的其他人遇到这个问题。

今天我得到了“等待锁定hg push命令上的“在存储库上”。 / lock命令挂起时,它存在。但是当hg命令被杀死时,锁文件被删除了。

当我去往push的目标并执行hg pull时,没问题。每次hg push上的进程ID为lock等待消息都在更改。事实证明,“ hg push”正在挂起,等待它自己持有的锁(或者可能是子进程,我没有进一步研究)。

事实证明,这两个工作区叫我们A和B具有通过symlink共享的.hg树:

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


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

评论


hg不会在.hg /中跟踪目录状态吗?当您说存储库“有效”时,是不是在其中一个运行了hg,却使另一个目录不同步?或者,mercurial是否做一些特殊的事情来支持这个?

– Binki
15年3月6日在16:27

您可以使用共享扩展名(Core Mercurial附带)在单个存储库中具有多个工作目录。

– Marmoute
2015年6月25日,0:47

#8 楼

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

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


hg debuglock显示了此信息:做了以下命令,并为我解决了问题:

lock:  free
wlock:  (66722s)


使用Win7和TortoiseHg 4.8.7。

#9 楼

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

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

#10 楼

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

评论


我发现以某种方式将默认路径设置为指向相同的存储库。这个。谢谢,您-我经过循环来解决问题,而路径设置才是罪魁祸首。

– WoJ
16年2月2日在8:40

#11 楼

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