Mercurial coincé "en attente de verrouillage"

346

Vous avez un écran bleu dans les fenêtres 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
en attente de verrouillage sur le référentiel c: \ src \ McVrsServer détenu par '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
interrompu!

Google n'est d'aucune aide.

Des conseils?

mercurial

— jm.
source

3

Wow, j'ai également eu un écran bleu lors de la validation et j'ai eu la même erreur. Content que je ne sois pas le seul!

— CBarr

3

J'ai proposé une meilleure rétroaction du message d'erreur sur bz.selenic.com/show_bug.cgi?id=4752

— Karl Richter

489

Lorsque "en attente de verrouillage sur le référentiel", supprimez le fichier du référentiel: .hg/wlock(ou il 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).

— jm.
source

103

Mon problème n'avait rien à voir avec le clonage ou BSOD mais pour moi, j'ai supprimé le fichier .hg / wlock pour effacer le verrou.

— frank hadder

32

hg recoverdoit être exécuté après une situation de verrouillage cassée.

— James Broadhead

9

Merci beaucoup - après avoir supprimé .hg / wlock, je ne savais pas quel était le problème

— Andrew Buss

34

Dans mon cas (TortoiseHg V2.9.2 avec Mercurial 2.7.2), le nom du fichier était "wlock" au lieu de "lock"; et il a été placé dans le répertoire ".hg", pas dans ".hg / store".

— Fernando

7

@Marmoute - le référentiel est verrouillé chaque fois qu'un changement va être effectué. Si quelque chose provoque l'échec de ce processus - c'est-à-dire un bogue dans Mercurial, une machine en panne, etc. - les fichiers de verrouillage restent, non nettoyés. Je pense que les suggestions ici pour supprimer manuellement les fichiers de verrouillage visent à résoudre les cas où le référentiel était en quelque sorte laissé dans un état "impur". Le qualifier de «supprimer aveuglément la protection contre le mercure» n'est pas une caractérisation juste et précise de ce qui se passe dans ces cas.

— JoGusto

345

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

— Tiago Matos
source

6

Ce fut le cas pour moi. C'était un lien symbolique sur 'nix vers le courant server:pid. Merci beaucoup. Ensuite, j'ai dû courir $ hg recoverpour effacer le journal existant (et le message de validation) que j'avais ctrl+cédité. Pas sûr, mais vous pourrez peut-être exécuter $ hg recoversans supprimer le fichier de verrouillage et il le fera pour vous. Ça vaut le coup je suppose.

— sholsinger

2

Juste une note pour @sholsinger pour dire que l'exécution de la récupération de hg ne fonctionne que si vous retirez d'abord le verrou. Je l'ai essayé.

— Dan

1

Le référentiel est verrouillé pour une raison, un autre processus travaille sur le référentiel. Vous devriez trouver ce processus et y mettre fin au lieu de supprimer aveuglément la protection mercurielle. La simple suppression du fichier peut entraîner une corruption du référentiel.

— Marmoute

@Marmoute Dans mon cas, j'ai dû retirer le verrou, car aucun autre processus ne fonctionnait sur le dépôt. Mais je suis d'accord, cela vaut la peine de chercher d'abord un autre processus

— Mi-La

J'ai reçu ce message soudainement en essayant de tirer, après avoir tiré et poussé pendant quelques jours sans problème. Après avoir supprimé le fichier, le problème a été résolu. Le fichier était de 0 Ko, ce qui signifie que je suppose qu'il était vide. Est-ce bien de supprimer simplement le fichier? Je suppose que c'est utile pour la protection.

— Ben Carp

47

J'ai eu ce problème avec aucun fichier de verrouillage détectable. 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, la traction avortée s'est déroulée avec succès.

Le verrou avait été défini 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 les supprimer automatiquement lorsqu'ils sont périmés.

— Thomas Sharpless
source

23

Protip: Si wlockc'est celui qui est enfermé, utilisezhg debuglocks --force-wlock

— Brad Turek

5

J'utilise la tortue hg depuis plus de 7 ans. Je n'ai jamais vu le problème jusqu'à il y a environ 3 mois. Je l'ai vu 3 fois au cours des 3 derniers mois. Certaines mises à jour ont dû exacerber le problème.

— d ei

20

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 bogue de TortoiseHG )

Puis son repo a de nouveau fonctionné.

EDIT: Selon le commentaire de @ Marmoute - lorsqu'il s'agit de problèmes liés aux verrous, l'utilisation hg debuglockest une alternative plus sûre à la suppression aveugle du .hg/store/lockfichier.

— Ian Kemp
source

2

1) Il n'y a absolument aucune raison de toucher le fichier phaseroots, cela n'a absolument rien à voir avec le verrouillage. 2) masquer la suppression du verrou est une mauvaise idée, il existe probablement un autre processus qui l'utilise. utilisez hg debuglock pour comprendre ce qui se passe et terminer le processus de verrouillage

— Marmoute

3

1) Considérant que sa suppression a résolu le problème, je serais en désaccord. 2) Je ne connaissais pas hg debuglock à l'époque (je ne trouve aucune documentation à ce sujet non plus), et puisque le système venait juste de redémarrer, il n'y avait évidemment rien de verrouillant le référentiel - donc la suppression du fichier de verrouillage était appropriée.

— Ian Kemp

12

Je connais très bien le code de verrouillage de Mercurial (depuis la version 1.9.1). Le conseil ci-dessus est bon, mais j'ajouterais que:

J'ai vu cela dans la nature, mais rarement et uniquement sur les machines Windows.
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, cela est presque certainement vrai).

(Pour les curieux: je n'ai pas encore pu identifier la cause de ce problème, mais je soupçonne 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.)

— Brad O
source

2

FWIW ça m'est juste arrivé sur Ubuntu. C'était la première fois que j'utilisais le référentiel depuis plusieurs semaines, donc je ne me souviens pas de ce qui aurait pu le laisser dans cet état.

— Cosmologicon

7

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

.hg / store / phaseroots
.hg / wlock

Quant à .hg / store / lock - il n'y avait pas un tel fichier.

— Ivan Dulov
source

Bienvenue sur Stackoverflow. Essayez d'ajouter plus de contenu à l'article

— NJInamdar

5

1) Il n'y a absolument aucune raison de toucher le fichier phaseroots, cela n'a absolument rien à voir avec le verrouillage. 2) masquer la suppression du verrou est une mauvaise idée, il y a probablement un autre processus qui l'utilise. utiliser hg debuglockpour comprendre ce qui se passe et terminer le processus de maintien du verrou.

— Marmoute

6

Je ne m'attends pas à ce que ce soit une réponse gagnante, mais c'est une situation assez inhabituelle. Mentionner au cas où quelqu'un d'autre que moi le rencontrerait.

Aujourd'hui, j'ai obtenu le "attente de verrouillage sur le référentiel" sur une commande hg push.

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

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

Quand je suis allé à la cible du push, et que j'ai exécuté le hg pull, pas de problème.

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

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

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 à Mercurial d'un autre VCS pourrait vouloir cela (Perforce le fait, mais pas un DVCS; le Bazaar DVCS pourrait le faire). Je suis surpris qu'un REP-ROOT / .hg avec lien symbolique fonctionne du tout, bien qu'il semble excepter cette poussée.

— Krazy Glew
source

Hg track n'a-t-il pas envie de rentrer .hg/? Lorsque vous dites que les référentiels «fonctionnent», le fait de fonctionner hg updans l'un ne désynchronise pas les autres - ou est-ce que mercurial fait quelque chose de spécial pour soutenir cela?

— binki

1

Vous pouvez utiliser l'extension de partage (fournie avec Core Mercurial) pour avoir plusieurs répertoires de travail à partir d'un même référentiel.

— Marmoute

4

J'ai eu le même problème. Vous avez le message suivant lorsque j'ai essayé de valider:

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

hg debuglock a montré ceci:

lock:  free
wlock:  (66722s)

J'ai donc fait la commande suivante, et cela a résolu le problème pour moi:

hg debuglocks -W

Utilisation de Win7 et TortoiseHg 4.8.7.

— user10125940
source

2

Si le dépôt verrouillé était l'original, je ne peux pas imaginer qu'il modifiait pour le cloner, donc cela vous empêchait seulement de le changer au milieu et de gâcher le clone. Ça devrait aller après avoir retiré le verrou.

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

— markpasc
source

2

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 "attendre le verrouillage du référentiel". J'ai découvert que le chemin par défaut avait été réglé pour pointer vers le même référentiel, il n'est donc pas trop surprenant que Mercurial soit confus.

— JWWalker
source

1

J'ai découvert que le chemin par défaut avait été réglé pour pointer vers le même référentiel . Cette. Merci, vous - j'ai parcouru des boucles pour me débarrasser du problème et le pathréglage était le coupable.

— WoJ

1

Si cela ne se produit que sur les lecteurs mappés, il peut s'agir du bogue 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.

— Matt Wilkie
source