Mercurial hängt fest "Warten auf Sperre"

Question

Ich habe einen Bluescreen in Windows beim Klonen eines Mercurial-Repositorys.

Nach dem Neustart erhalte ich nun diese Meldung für fast alle hg-Befehle:

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 ist keine Hilfe.

Irgendwelche Tipps?

Answer 1

Wenn Sie auf die Sperre des Repositorys warten, löschen Sie die Repository-Datei: .hg/wlock (oder es kann in .hg/store/lock )

Wenn Sie die Sperrdatei löschen, müssen Sie sicherstellen, dass keine anderen Benutzer auf das Repository zugreifen. (Wenn die Sperre aus einer Reihe von Nullen oder Leerzeichen besteht, ist dies fast sicher der Fall).

Answer 2

Wenn waiting for lock on working directory , löschen .hg/wlock .

Answer 3

Ich hatte das Problem, dass keine Sperrdateien auffindbar waren. Ich habe die Lösung hier gefunden: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Hier ist eine Abschrift der Tortoise Hg Workbench Konsole

% 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]

Danach lief der abgebrochene Zug erfolgreich.

Die Sperre wurde vor mehr als 2 Jahren von einem Prozess auf einem Rechner gesetzt, der sich nicht mehr im LAN befindet. Schande über die hg-Entwickler, weil sie a) Sperren nicht angemessen dokumentieren; b) sie nicht mit einem Zeitstempel versehen, um sie automatisch zu entfernen, wenn sie veraltet sind.

Answer 4

Ein Kollege hatte heute genau dieses Problem, nach einem BSoD beim Versuch zu pressen. Das musste er:

• Löschen Sie die Datei .hg/store/lock (gemäß die akzeptierte Antwort )
• Löschen Sie die Datei .hg/store/phaseroots (gemäß dieser TortoiseHG Fehlerbericht )

Dann funktionierte sein Repo wieder.

EDITAR: Wie in @Marmoutes Kommentar erwähnt, sollten Sie bei Problemen mit der Sperre die hg debuglock ist eine sicherere Alternative zum blinden Löschen der .hg/store/lock Datei.

Answer 5

Ich bin sehr vertraut mit dem Sperrcode von Mercurial (ab 1.9.1). Der obige Ratschlag ist gut, aber ich würde hinzufügen, dass:

1. Ich habe das in freier Wildbahn gesehen, aber selten und nur auf Windows-Rechnern.
2. Das Löschen von Sperrdateien ist die einfachste Lösung, ABER Sie müssen sicherstellen, dass keine anderen Benutzer auf das Repository zugreifen. (Wenn die Sperre aus einer Reihe von Nullen besteht, ist dies fast sicher der Fall).

(Für Neugierige: Ich konnte die Ursache für dieses Problem noch nicht herausfinden, vermute aber, dass es sich entweder um eine ältere Version von Mercurial handelt, die auf das Repository zugreift, oder um ein Problem in Pythons socket.gethostname()-Aufruf auf bestimmten Windows-Versionen).