Mercurial preso “esperando bloqueio”

StackOverflow https://stackoverflow.com/questions/12865

  •  08-06-2019
  •  | 
  •  

Pergunta

Ocorreu uma tela azul no Windows ao clonar um repositório mercurial.

Após a reinicialização, recebo esta mensagem para quase todos os comandos 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!

O Google não ajuda.

Alguma dica?

Foi útil?

Solução

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

Ao excluir o arquivo de bloqueio, você deve certificar-se de que nada mais esteja acessando o repositório.(Se o bloqueio for uma sequência de zeros ou em branco, isso quase certamente é verdade).

Outras dicas

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

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 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, o pull abortado foi executado com sucesso.

O bloqueio foi 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 do hg por a) não documentarem os bloqueios adequadamente;b) não carimbá-los para remoção automática quando ficarem obsoletos.

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

Então seu repo funcionou novamente.

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

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:

  1. Já vi isso na natureza, mas raramente e apenas em máquinas Windows.
  2. Excluir arquivos de bloqueio é a solução mais fácil, MAS você precisa ter certeza de que nada mais está acessando o repositório.(Se o bloqueio for uma sequência de zeros, isso quase certamente é verdade).

(Para os curiosos:Ainda não consegui identificar a causa desse problema, mas suspeito que seja uma versão mais antiga do Mercurial acessando o repositório ou um problema na chamada socket.gethostname() do Python em determinadas versões do Windows.)

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

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

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

Não espero que esta seja uma resposta vencedora, mas é uma situação bastante incomum.Mencionando caso alguém que não seja eu se depare com isso.

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

Quando eu matei o comando hg pendurado, não consegui ver nenhum .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 eliminado.

Quando fui até o alvo do push e executei hg pull, sem problemas.

Eventualmente, percebi que o ID do processo no hg push era uma mensagem de espera de bloqueio que mudava a cada vez.Acontece que o "hg push" estava pendurado esperando por um bloqueio mantido por si mesmo (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 por link simbólico:

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

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

Se o repositório bloqueado fosse o original, não consigo imaginar que fosse modificando cloná-lo, então só impedia que você mudasse no meio e estragasse o clone.Deve ficar bem depois de remover a trava.

A nova cópia clonada (se fosse um clone local) poderia estar em qualquer tipo de estado malformado, então você deve jogá-la fora e reiniciá-la.(Se fosse um clone remoto, espero que tenha falhado e já tenha descartado a cópia incompleta.)

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

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

Eu tive o mesmo problema.Recebi a seguinte mensagem quando tentei confirmar:aguardando bloqueio no diretório de trabalho mantido por ''

hg debuglock mostrou isso:trancar:Wlock grátis:(66722s)

Então executei o seguinte comando e isso resolveu o problema para mim:hg debuglocks -W

Usando Win7 e TortoizeHg 4.8.7.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top