Mercurial preso "esperando bloqueio"

346

Obteve uma tela azul no Windows enquanto clonava um repositório mercurial.

Após a reinicialização, agora recebo esta mensagem para quase todos os comandos hg:

c: \ src \> hg commit
aguardando bloqueio no repositório c: \ src \ McVrsServer mantido por '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
interrompido!

Google não ajuda.

Alguma dica?

mercurial

— jm.
fonte

3

Uau, eu também tive uma tela azul ao confirmar e recebi o mesmo erro. Ainda bem que não sou o único!

— CBarr

3

Propus melhor retorno da mensagem de erro no bz.selenic.com/show_bug.cgi?id=4752

— Karl Richter

489

Ao "aguardar bloqueio no repositório", exclua o arquivo do repositório: .hg/wlock(ou pode estar dentro .hg/store/lock)

Ao excluir o arquivo de bloqueio, verifique se nada mais está acessando o repositório. (Se o bloqueio for uma sequência de zeros ou em branco, isso é quase certo).

— jm.
fonte

103

Meu problema não tinha nada a ver com clonagem ou BSOD, mas, para mim, excluí o arquivo .hg / wlock para limpar o bloqueio.

— Hadder franca

32

hg recoverdeve ser executado após uma situação de bloqueio quebrado.

— James Broadhead

9

Muito obrigado - depois de remover .hg / WLock Eu não tinha idéia de qual era o problema

— Andrew Buss

34

No meu caso (TortoiseHg V2.9.2 com Mercurial 2.7.2), o nome do arquivo era "wlock" em vez de "lock"; e foi colocado no diretório ".hg", não em ".hg / store".

— Fernando

7

@Armoute - o repositório fica bloqueado sempre que uma alteração for feita. Se algo fizer com que esse processo falhe - ou seja, um bug no Mercurial, uma máquina caindo, etc. - os arquivos de bloqueio permanecerão, não limpos. Eu acredito que as sugestões aqui para excluir os arquivos de bloqueio manualmente são para resolver os casos em que o repositório foi deixado de alguma forma em um estado "impuro". Chamá-lo de "remover cegamente a proteção mercurial" não é uma caracterização justa nem precisa do que está acontecendo nesses casos.

— JoGusto

345

Quando waiting for lock on working directory, apague .hg/wlock.

— Tiago Matos
fonte

6

Esse foi o meu caso. Era um link simbólico do nix para o atual server:pid. Muito obrigado. Então tive que correr $ hg recoverpara limpar o diário existente (e confirmar a mensagem) que ctrl+ceditei. Não tenho certeza, mas você pode executar $ hg recoversem excluir o arquivo de bloqueio e ele fará isso por você. Vale uma chance, suponho.

— sholsinger

2

Apenas uma observação para @sholsinger dizer que a execução do hg recover não funcionará, a menos que você remova o bloqueio primeiro. Eu tentei.

— Dan

11

Repositório bloqueado por um motivo, outro processo está trabalhando no repositório. Você deve encontrar esse processo e finalizá-lo em vez de remover cegamente a proteção mercurial. Apenas soltar o arquivo pode levar à corrupção do repositório.

— Marmoute

@Armoute No meu caso, tive que remover a trava, porque nenhum outro processo estava funcionando no repositório. Mas concordo, vale a pena procurar outro processo primeiro #

— Mi-La

Recebi esta mensagem repentinamente ao tentar puxar, depois de puxar e empurrar por alguns dias sem problemas. Depois de excluir o arquivo, o problema foi resolvido. O arquivo tinha 0 KB, o que significa que acho que estava vazio. É bom simplesmente excluir o arquivo? Eu acho que é útil para proteção.

— Ben Carp

47

Eu tive esse problema sem arquivos de bloqueio detectáveis. Encontrei a solução aqui: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Aqui está uma transcrição do console do 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]

Depois disso, a atração abortada foi executada com sucesso.

O bloqueio havia sido definido há mais de 2 anos, por um processo em uma máquina que não está mais na LAN. Que vergonha para os desenvolvedores de hg: a) não documentarem adequadamente os bloqueios; b) não marcá-los com carimbo de data / hora para remoção automática quando ficarem obsoletos.

— Thomas Sharpless
fonte

23

Protip: Se wlocké o preso, usohg debuglocks --force-wlock

— Brad Turek

5

Eu uso tartaruga hg há mais de 7 anos. Eu nunca vi o problema até cerca de 3 meses atrás. Eu já vi 3 vezes nos últimos 3 meses. Alguma atualização deve ter exacerbado o problema.

— d ei

20

O colega de trabalho teve esse problema exato hoje, depois de um BSoD ao tentar empurrar. Ele teve que:

exclua o arquivo .hg/store/lock(conforme a resposta aceita )
exclua o arquivo .hg/store/phaseroots(conforme este relatório de bug do TortoiseHG )

Então seu repo funcionou novamente.

EDIT: De acordo com o comentário de @ Marmoute - ao lidar com problemas relacionados a bloqueios, usar hg debuglocké uma alternativa mais segura para excluir cegamente o .hg/store/lockarquivo.

— Ian Kemp
fonte

2

1) Não existe absolutamente nenhuma razão para você tocar no arquivo phaseroots, pois ele não tem nenhuma relação com o bloqueio. 2) remover cegamente a remoção do wlock é uma péssima idéia, provavelmente existe outro processo usando-o. usar debuglock hg para descobrir o que acontecer e encerrar o processo segurando o bloqueio

— Marmoute

3

1) Considerando que removê-lo resolveu o problema, eu teria que discordar. 2) Não sabia sobre o hg debuglock no momento (também não pode encontrar nenhuma documentação) e, como o sistema havia acabado de reiniciar, obviamente não havia nada bloqueando o repositório - portanto, excluir o arquivo de bloqueio era apropriado.

— Ian Kemp

12

Estou muito familiarizado com o código de bloqueio do Mercurial (a partir de 1.9.1). O conselho acima é bom, mas eu acrescentaria que:

Eu já vi isso na natureza, mas raramente e apenas em máquinas Windows.
Excluir arquivos de bloqueio é a correção mais fácil, MAS você precisa garantir que nada mais esteja acessando o repositório. (Se o bloqueio é uma sequência de zeros, isso é quase certo).

(Para quem está curioso: ainda não consegui entender a causa desse problema, mas desconfio que seja uma versão mais antiga do Mercurial acessando o repositório ou um problema no socket.gethostname () do Python chamar determinadas versões do Windows.)

— Brad O
fonte

2

FWIW, aconteceu comigo no Ubuntu. Foi minha primeira vez usando o repositório em várias semanas, então não me lembro do que poderia ter deixado nesse estado.

— 18714 Cosmologicon

7

Eu tive o mesmo problema no Win 7. A solução foi remover os seguintes arquivos:

.hg / store / phaseroots
.hg / wlock

Quanto a .hg / store / lock - não havia esse arquivo.

— Ivan Dulov
fonte

Bem-vindo ao Stackoverflow. Tente adicionar mais conteúdo para o cargo

— NJInamdar

5

1) Não existe absolutamente nenhuma razão para você tocar no arquivo phaseroots, pois ele não tem nenhuma relação com o bloqueio. 2) remover cegamente a remoção do wlock é uma péssima idéia, provavelmente existe outro processo usando-o. use hg debuglockpara descobrir o que está acontecendo e encerrar o processo segurando a trava.

— Marmoute

6

Não espero que seja uma resposta vencedora, mas é uma situação bastante incomum. Mencionando no caso de alguém que não seja eu.

Hoje recebi o "aguardando bloqueio no repositório" em um comando hg push.

Quando eu matei o comando hg desligado, não pude ver .hg / store / lock

Quando procurei .hg / store / lock enquanto o comando estava travado, ele existia. Mas o arquivo de bloqueio foi excluído quando o comando hg foi morto.

Quando fui ao alvo do push e executei hg pull, não há problema.

Eventualmente, percebi que o ID do processo no hg push era bloqueado, a mensagem em espera estava mudando a cada vez. Acontece que o "hg push" estava pendurado, aguardando uma trava mantida sozinha (ou possivelmente um subprocesso, não investiguei mais).

Acontece que os dois espaços de trabalho, vamos chamá-los de A e B, tinham árvores .hg compartilhadas pelo link simbólico:

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

Isso não é uma coisa boa a fazer com o Mercurial. O Mercurial não entende o conceito de dois espaços de trabalho que compartilham o mesmo repositório. Eu entendo, no entanto, como alguém que vem para a Mercurial de outro VCS pode querer isso (a Perforce, embora não seja um DVCS; o Bazaar DVCS pode fazê-lo). Estou surpreso que um REP-ROOT / .hg com link simbólico funcione, embora pareça exceto esse impulso.

— Krazy Glew
fonte

O hg não rastreia o estado .hg/? Quando você diz que os repositórios “funcionam”, a execução hg upem um não deixa o estado estável fora de sincronia no outro - ou o mercurial faz algo especial para apoiar isso?

— binki

11

Você pode usar a extensão de compartilhamento (fornecida com o Core Mercurial) para ter vários diretórios de trabalho em um único repositório.

— Marmoute

4

Eu tive o mesmo problema. Recebi a seguinte mensagem quando tentei confirmar:

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

hg debuglock mostrou isso:

lock:  free
wlock:  (66722s)

Então, eu fiz o seguinte comando, e isso corrigiu o problema para mim:

hg debuglocks -W

Usando Win7 e TortoiseHg 4.8.7.

— user10125940
fonte

2

Se o repositório bloqueado era o original, não consigo imaginar que o estava modificando para cloná-lo, por isso estava apenas impedindo que você o alterasse no meio e estragasse o clone. Deve ficar bem depois de remover a trava.

A nova cópia clonada (se fosse um clone local) pode estar em qualquer tipo de estado incorreto; portanto, você deve descartá-la e iniciá-la novamente. (Se fosse um clone remoto, espero que tenha falhado e já tenha jogado fora a cópia incompleta.)

— markpasc
fonte

2

Encontrei esse problema no Mac OS X 10.7.5 e no Mercurial 2.6.2 ao tentar enviar por push. Após a atualização para o Mercurial 3.2.1, obtive "nenhuma alteração encontrada" em vez de "aguardar o bloqueio no repositório". Descobri que, de alguma forma, o caminho padrão foi definido para apontar para o mesmo repositório, portanto, não é de surpreender que o Mercurial fique confuso.

— JWWalker
fonte

11

Descobri que, de alguma forma, o caminho padrão havia sido definido para apontar para o mesmo repositório . Este. Obrigado, você - eu passei por loops para me livrar do problema e dapath cenário foi o culpado.

— woj

1

Se isso acontecer apenas em unidades mapeadas, pode ser um bug https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . O uso do caminho UNC em vez da letra da unidade parece contornar o problema.

— Matt Wilson
fonte