Mercurial坚持"等待锁定"

Question

Mercurial坚持"等待锁定"

在克隆一个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

jm.*_*jm. 482

当"等待锁定存储库"时,删除存储库文件:.hg/wlock或者可能在.hg/store/lock



删除锁定文件时,必须确保没有其他内容正在访问存储库.(如果锁是一串零,这几乎肯定是正确的).

        
          
          
              我的问题与克隆或BSOD无关,但对我来说,我删除了.hg/wlock文件以清除锁定. (102认同)
           
          
          
              在我的案例中(TortoiseHg V2.9.2 with Mercurial 2.7.2),文件名是"wlock"而不是"lock"; 它被放置在".hg"目录中,而不是".hg/store"中. (33认同)
           
          
          
              应该在锁定情况破坏后运行`hg recover`. (31认同)
           
          
          
              非常感谢 - 删除.hg/wlock后我不知道问题是什么 (9认同)
           
          
          
              @Marmoute  - 无论何时进行更改,存储库都会被锁定.如果某些事情导致该过程失败 - 即Mercurial中的错误,机器停机等 - 锁定文件仍然存在,而不是清理.我相信这里手动删除锁文件的建议是为了解决存储库以某种方式处于"不干净"状态的情况.将其称为"盲目地取消汞的保护"并不是对这些案件中发生的事情进行公平或准确的描述. (6认同)
           
          
          
              是的,我认为如果您的系统遇到困难,那么您需要做的是:"hg commit等待锁定存储库" (2认同)
           
          
          
              存储库因某种原因而被锁定,另一个进程正在处理存储库.您应该找到该过程并终止它,而不是盲目地删除mercurial保护.删除文件可能会导致存储库损坏. (2认同)
           
          
          
              我在.hg/store中没有这样的文件但是在.hg /中有一个名为wlock的文件并且删除它解决了问题(对repo没有任何明显的损害). (2认同)

Answer 2

小智 344

When waiting for lock on working directory, delete .hg/wlock.

这就是我的情况.它是'nix到当前`服务器的符号链接:pid`.谢谢一堆.然后我不得不运行`$ hg recover`来清除现有的日志(和提交消息),我按住ctrl + c`'.不确定,但你可以运行`$ hg recover`而不删除锁文件,它会为你做.我想是值得一试. (6认同)
删除.hg/wlock也适合我. (2认同)
只是注意@sholsinger说除非你先删除锁,否则运行hg recover不起作用.我尝试过这个. (2认同)

Answer 3

Tho*_*ess 46

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

Run Code Online (Sandbox Code Playgroud)

在此之后,流产的拉动成功.

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

Protip:如果`wlock`被锁定,请使用`hg debuglocks --force-wlock` (22认同)
我已经使用了5年以上的龟.直到大约3个月前我才从未见过这个问题.我在过去3个月里见过3次.某些更新必定会加剧问题. (5认同)

Answer 4

Ian*_*emp 20

在尝试推动BSoD之后,今天同事确实遇到了这个问题.他不得不:

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

然后他的回购再次奏效.

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

1)考虑到删除它解决了问题,我不得不反对.2)当时不知道hg debuglock(也找不到任何文档),并且由于系统刚从重启中出现,显然没有锁定存储库 - 因此删除锁定文件是合适的. (3认同)
1)绝对没有理由你应该触摸相位文件,它绝对与锁定无关.2)盲目移除wlock是一个坏主意,可能还有另一个使用它的过程.使用hg debuglock来弄清楚它发生了什么并终止持有锁的进程 (2认同)

Answer 5

小智 12

我对Mercurial的锁定代码非常熟悉(截至1.9.1).上述建议很好,但我补充一点:

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

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

FWIW刚刚在Ubuntu发生在我身上.这是我几周以来第一次使用存储库,所以我不记得在那个状态下可能会留下什么. (2认同)

Answer 6

小智 7

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

.hg /存储/ phaseroots
.hg/wlock

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

1)绝对没有理由你应该触摸相位文件,它绝对与锁定无关.2)盲目移除wlock是一个坏主意,可能还有另一个使用它的过程.使用`hg debuglock`来弄清楚它发生了什么并终止持有锁的进程. (5认同)

Answer 7

小智 7

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

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

Run Code Online (Sandbox Code Playgroud)

hg debuglock 显示了这一点：

lock:  free
wlock:  (66722s)

Run Code Online (Sandbox Code Playgroud)

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

hg debuglocks -W

Run Code Online (Sandbox Code Playgroud)

使用 Win7 和 TortoiseHg 4.8.7。

Answer 8

Kra*_*lew 5

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

今天我在hg push命令上得到了"等待锁定存储库".

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

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

当我去推动目标,并执行hg拉,没问题.

最终我意识到hg push上的进程ID是锁定等待消息每次都在改变.事实证明,"hg push"正在等待自己持有的锁(或者可能是子进程,我没有进一步调查).

事实证明,两个工作区,我们称之为A和B,由符号链接共享.hg树:

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

Run Code Online (Sandbox Code Playgroud)

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

归档时间：	17 年，2 月前
查看次数：	101604 次
最近记录：	6 年，2 月前