Mercurial bloqué "en attente de verrouillage"

Question

Vous avez un écran bleu dans Windows lors du clonage d'un référentiel Mercurial.

Après le redémarrage, je reçois maintenant ce message pour presque toutes les commandes 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!

Google n'est d'aucune aide.

Des conseils ?

Answer 1

Lorsque vous "attendez le verrouillage du référentiel", supprimez le fichier du référentiel : .hg/wlock (ou c'est peut-être dans .hg/store/lock)

Lors de la suppression du fichier de verrouillage, vous devez vous assurer que rien d'autre n'accède au référentiel.(Si le verrou est une chaîne de zéros ou vide, c'est presque certainement vrai).

Answer 2

Quand waiting for lock on working directory, supprimer .hg/wlock.

Answer 3

J'ai eu ce problème sans fichiers de verrouillage détectables.J'ai trouvé la solution ici : http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Voici une transcription de la 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]

Après cela, l'extraction interrompue s'est déroulée avec succès.

Le verrou avait été posé il y a plus de 2 ans, par un processus sur une machine qui n'est plus sur le LAN.Honte aux développeurs hg pour a) ne pas documenter correctement les verrous ;b) ne pas les horodater pour une suppression automatique lorsqu'ils deviennent obsolètes.

Answer 4

Un collègue a eu exactement ce problème aujourd'hui, après un BSoD en essayant de pousser.Il le devait:

• supprimer le fichier .hg/store/lock (selon la réponse acceptée)
• supprimer le fichier .hg/store/phaseroots (selon ce rapport de bug de TortoiseHG)

Ensuite, son repo a fonctionné à nouveau.

MODIFIER: Selon le commentaire de @Marmoute - lorsque vous traitez des problèmes liés au verrouillage, en utilisant hg debuglock est une alternative plus sûre à la suppression aveugle du .hg/store/lock déposer.

Answer 5

Je connais très bien le code de verrouillage de Mercurial (à partir de la version 1.9.1).Les conseils ci-dessus sont bons, mais j'ajouterais que :

1. J'ai vu cela dans la nature, mais rarement et uniquement sur les machines Windows.
2. La suppression des fichiers de verrouillage est la solution la plus simple, MAIS vous devez vous assurer que rien d'autre n'accède au référentiel.(Si le verrou est une chaîne de zéros, c'est presque certainement vrai).

(Pour les curieux :Je n'ai pas encore réussi à comprendre la cause de ce problème, mais je pense qu'il s'agit soit d'une ancienne version de Mercurial accédant au référentiel, soit d'un problème dans l'appel socket.gethostname() de Python sur certaines versions de Windows.)

Answer 6

J'ai eu le même problème sur Win 7.La solution consistait à supprimer les fichiers suivants :

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

Quant à .hg/store/lock, il n’existait pas de fichier de ce type.

Answer 7

Je ne m’attends pas à ce que ce soit une réponse gagnante, mais il s’agit d’une situation assez inhabituelle.Je le mentionne au cas où quelqu'un d'autre que moi tomberait dessus.

Aujourd'hui, j'ai reçu le message "en attente de verrouillage sur le référentiel" sur une commande hg push.

Quand j'ai tué la commande hg bloquée, je n'ai vu aucun .hg/store/lock

Lorsque j'ai cherché .hg/store/lock pendant que la commande était bloquée, elle existait.Mais le fichier de verrouillage a été supprimé lorsque la commande hg a été supprimée.

Quand je suis allé vers la cible de la poussée et que j'ai exécuté hg pull, pas de problème.

Finalement, j'ai réalisé que l'ID de processus sur le hg push était un message de verrouillage en attente qui changeait à chaque fois.Il s'avère que le "hg push" était suspendu en attendant un verrou détenu par lui-même (ou peut-être un sous-processus, je n'ai pas enquêté davantage).

Il s'avère que les deux espaces de travail, appelons-les A et B, avaient des arbres .hg partagés par lien symbolique :

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

Ce n'est PAS une bonne chose à faire avec Mercurial.Mercurial ne comprend pas le concept de deux espaces de travail partageant le même référentiel.Je comprends cependant comment quelqu'un venant sur Mercurial depuis un autre VCS pourrait vouloir cela (Perforce le fait, bien qu'il ne s'agisse pas d'un DVCS ;le Bazaar DVCS serait apparemment en mesure de le faire).Je suis surpris qu'un lien symbolique REP-ROOT/.hg fonctionne, même s'il semble que ce soit le cas, sauf pour cette poussée.

Answer 8

Si le dépôt verrouillé était l'original, je ne peux pas imaginer que ce soit le cas modification pour le cloner, donc cela vous empêchait seulement de le changer au milieu et de gâcher le clone.Tout devrait bien se passer après avoir retiré le verrou.

La nouvelle copie clonée (s'il s'agissait d'un clone local) pourrait cependant être dans n'importe quel état malformé, vous devez donc la jeter et la recommencer.(S'il s'agissait d'un clone distant, j'espère qu'il échouera et qu'il aura déjà jeté la copie incomplète.)

Answer 9

J'ai rencontré ce problème sur Mac OS X 10.7.5 et Mercurial 2.6.2 en essayant de pousser.Après la mise à niveau vers Mercurial 3.2.1, j'ai obtenu « aucune modification trouvée » au lieu de « en attente de verrouillage sur le référentiel ».J'ai découvert que d'une manière ou d'une autre, le chemin par défaut avait été configuré pour pointer vers le même référentiel, il n'est donc pas surprenant que Mercurial soit confus.

Answer 10

Si cela ne se produit que sur les lecteurs mappés, il peut s'agir d'un bug https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share.L'utilisation du chemin UNC au lieu de la lettre de lecteur semble contourner le problème.

Answer 11

J'ai eu le même problème.J'ai reçu le message suivant lorsque j'ai essayé de valider :en attente de verrouillage sur le répertoire de travail détenu par ''

hg debuglock a montré ceci :verrouillage:Wlock gratuit:(66722s)

J'ai donc exécuté la commande suivante, et cela a résolu le problème pour moi :hg débogage -W

Utilisation de Win7 et TortoizeHg 4.8.7.