Mercurial steckt fest und wartet auf Sperre

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

  •  08-06-2019
  •  | 
  •  

Frage

Beim Klonen eines Quecksilber-Repositorys ist in Windows ein Bluescreen aufgetreten.

Nach dem Neustart erhalte ich nun bei fast allen hg-Befehlen diese Meldung:

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?

War es hilfreich?

Lösung

Wenn Sie auf die Sperre für das Repository warten, löschen Sie die Repository-Datei: .hg/wlock (Oder es könnte drin sein .hg/store/lock)

Beim Löschen der Sperrdatei müssen Sie sicherstellen, dass nichts anderes auf das Repository zugreift.(Wenn die Sperre eine Folge von Nullen oder Leerzeichen ist, ist dies mit ziemlicher Sicherheit der Fall.)

Andere Tipps

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

Ich hatte dieses Problem, da keine Sperrdateien erkennbar waren.Die Lösung habe ich hier gefunden: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Hier ist ein Transkript 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 Pull erfolgreich.

Die Sperre wurde vor mehr als zwei Jahren durch einen Prozess auf einem Computer gesetzt, der sich nicht mehr im LAN befindet.Schade für die hg-Entwickler, weil sie a) Sperren nicht ausreichend dokumentiert haben;b) sie nicht mit einem Zeitstempel versehen, damit sie automatisch entfernt werden, wenn sie veraltet sind.

Ein Kollege hatte heute genau dieses Problem, nach einem BSoD beim Versuch zu pushen.Er musste:

Dann funktionierte sein Repo wieder.

BEARBEITEN: Gemäß dem Kommentar von @Marmoute – wenn es um Probleme im Zusammenhang mit Sperren geht, verwenden Sie hg debuglock ist eine sicherere Alternative zum blinden Löschen .hg/store/lock Datei.

Ich bin mit dem Sperrcode von Mercurial sehr vertraut (ab 1.9.1).Der obige Rat ist gut, aber ich möchte Folgendes hinzufügen:

  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 nichts anderes auf das Repository zugreift.(Wenn die Sperre eine Folge von Nullen ist, ist dies mit ziemlicher Sicherheit der Fall.)

(Für Neugierige:Ich konnte die Ursache dieses Problems 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 im Python-Aufruf socket.gethostname() bei bestimmten Windows-Versionen.)

Ich hatte das gleiche Problem unter Win 7.Die Lösung bestand darin, die folgenden Dateien zu entfernen:

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

Was .hg/store/lock betrifft – es gab keine solche Datei.

Ich erwarte nicht, dass dies eine überzeugende Antwort ist, aber es ist eine ziemlich ungewöhnliche Situation.Erwähnenswert für den Fall, dass jemand anders als ich darauf stößt.

Heute habe ich bei einem hg-Push-Befehl die Meldung „Warten auf Sperre für Repository“ erhalten.

Als ich den hängengebliebenen hg-Befehl beendete, konnte ich keine .hg/store/lock sehen

Als ich nach .hg/store/lock suchte, während der Befehl hängen blieb, war er vorhanden.Die Sperrdatei wurde jedoch gelöscht, als der Befehl hg beendet wurde.

Als ich zum Ziel des Pushs ging und hg pull ausführte, war das kein Problem.

Irgendwann wurde mir klar, dass sich die Prozess-ID in der Meldung „hg push war lock waiting“ jedes Mal änderte.Es stellte sich heraus, dass der „hg push“ hing und auf eine von ihm selbst gehaltene Sperre wartete (oder möglicherweise auf einen Unterprozess, den ich nicht weiter untersucht habe).

Es stellt sich heraus, dass die beiden Arbeitsbereiche, nennen wir sie A und B, .hg-Bäume hatten, die per Symlink geteilt wurden:

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

Das ist mit Mercurial KEINE gute Sache.Mercurial versteht das Konzept von zwei Arbeitsbereichen, die sich dasselbe Repository teilen, nicht.Ich verstehe jedoch, dass jemand, der von einem anderen VCS zu Mercurial kommt, dies haben möchte (Perforce tut das, obwohl es kein DVCS ist;Berichten zufolge kann das Bazaar DVCS dies tun.Ich bin überrascht, dass ein symbolisch verknüpftes REP-ROOT/.hg überhaupt funktioniert, auch wenn es bis auf diesen Push anscheinend funktioniert.

Wenn das gesperrte Repo das Original war, kann ich mir nicht vorstellen, dass es das war modifizieren Es hat Sie also nur daran gehindert, es mittendrin zu ändern und den Klon durcheinander zu bringen.Nach dem Entfernen des Schlosses sollte alles in Ordnung sein.

Die neue geklonte Kopie (wenn es sich um einen lokalen Klon handelte) könnte sich jedoch in einem beliebigen fehlerhaften Zustand befinden, daher sollten Sie sie wegwerfen und von vorne beginnen.(Wenn es sich um einen Remote-Klon handeln würde, würde ich hoffen, dass er fehlgeschlagen ist und die unvollständige Kopie bereits verworfen hat.)

Beim Push-Versuch ist dieses Problem unter Mac OS X 10.7.5 und Mercurial 2.6.2 aufgetreten.Nach dem Upgrade auf Mercurial 3.2.1 erhalte ich die Meldung „Keine Änderungen gefunden“ statt „Warten auf Sperre für Repository“.Ich habe herausgefunden, dass der Standardpfad irgendwie so eingestellt wurde, dass er auf dasselbe Repository verweist, sodass es nicht allzu überraschend ist, dass Mercurial verwirrt ist.

Wenn es nur auf zugeordneten Laufwerken auftritt, liegt möglicherweise ein Fehler vor https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share.Die Verwendung eines UNC-Pfads anstelle eines Laufwerksbuchstabens scheint das Problem zu umgehen.

Ich hatte das gleiche Problem.Als ich versuchte, einen Commit durchzuführen, erhielt ich die folgende Meldung:Warten auf Sperre für das Arbeitsverzeichnis, das von '' gehalten wird

hg debuglock hat Folgendes angezeigt:sperren:kostenlos wlock:(66722s)

Also habe ich den folgenden Befehl ausgeführt, und das hat das Problem für mich behoben:hg debuglocks -W

Mit Win7 und TortoizeHg 4.8.7.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top