Mercurial coincé “en attente de serrure”

Vous avez un écran bleu dans Windows tout en clonant un repository 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 locking sur le référentiel c: \ src \ McVrsServer tenu par '\ x00 \ x00 \ x00 \ x00 \ x00 \
 x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
 interrompu!

Google n’est pas une aide.

Des conseils?

Lorsque “attente du locking sur le référentiel”, supprimez le fichier de référentiel: .hg/store/lock ou peut-être en .hg/wlock

Lors de la suppression du fichier de locking, 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).

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

J’ai eu ce problème sans fichiers de locking 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, la traction avortée a réussi.

La serrure avait été réglée il y a plus de 2 ans, par un processus sur une machine qui n’est plus sur le réseau local. Honte aux développeurs de hg pour a) ne pas documenter les verrous correctement; b) ne pas les horodater pour un retrait automatique lorsqu’ils sont périmés.

Collaborateur avait ce problème exact 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 fonctionné à nouveau.

EDIT: Conformément au commentaire de @ Marmoute – en ce qui concerne les problèmes liés aux verrous, l’utilisation de hg debuglock est une alternative plus sûre à la suppression aveugle du .hg/store/lock .

Je connais très bien le code de locking de Mercurial (à partir de 1.9.1). Les conseils ci-dessus sont bons, mais j’appendais que:

  1. Je l’ai vu dans la nature, mais rarement, et uniquement sur les machines Windows.
  2. La suppression des fichiers de locking 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 été en mesure de déterminer la cause de ce problème, mais je pense que c’est soit une ancienne version de Mercurial accédant au référentiel, soit un problème avec socket.gethostname () sur certaines versions de Windows.)

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

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

En ce qui concerne .hg / store / lock – il n’y avait pas de tel fichier.

Je ne m’attends pas à ce que ce soit une réponse gagnante, mais c’est une situation assez inhabituelle. Mentionnant au cas où quelqu’un d’autre que moi se heurterait à cela.

Aujourd’hui, j’ai la “attente du verrou sur le repository” sur une commande hg push.

Quand j’ai tué la commande hung hg, je ne pouvais pas voir .hg / store / lock

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

Quand je suis allé à la cible de la poussée et exécuté hg pull, pas de problème.

Finalement, j’ai réalisé que l’ID de processus sur le push de hg était un message de locking en attente de modification à chaque fois. Il se trouve que le “hg push” était suspendu en attente d’un verrou tenu par lui-même (ou peut-être un sous-processus, je n’ai pas enquêté plus loin).

Il s’avère que les deux espaces de travail, appelons-les A et B, ont des arbres .hg partagés par un 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 toutefois comment une personne venant chez Mercurial à partir d’un autre VCS pourrait le vouloir (mais Perforce le fait, même si ce n’est pas un DVCS; le DVBS Bazaar pourrait le faire). Je suis surpris qu’un REP-ROOT / .hg avec liens symboliques fonctionne, bien qu’il semble y avoir une exception.

Si le repo verrouillé était l’original, je ne peux pas imaginer qu’il le modifiait pour le cloner, donc cela ne vous empêchait pas de le modifier au milieu et de gâcher le clone. Cela devrait aller après avoir enlevé la serrure.

La nouvelle copie clonée (si c’était un clone local) pourrait être dans un état mal formé, donc vous devriez la jeter et la recommencer. (Si c’était un clone à distance, j’espère qu’il a échoué et jette déjà la copie incomplète.)

Si cela ne se produit que sur les lecteurs mappés, cela peut être 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.

J’ai rencontré ce problème sous 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 “aucun changement trouvé” au lieu de “attendre le locking sur le référentiel”. J’ai découvert que le chemin par défaut avait été défini pour pointer vers le même référentiel, il n’est donc pas surprenant que Mercurial devienne confus.

J’ai eu le même problème. J’ai reçu le message suivant lorsque j’ai décidé de valider: en attente de locking sur le répertoire de travail de hold by ”

hg debuglock montre 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

Utiliser Win7 et TortoizeHg 4.8.7.