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

Ich hatte das gleiche Problem. Ich erhielt die folgende Meldung, als ich versuchte, die Daten zu übertragen:

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

hg debuglock zeigte dies:

lock:  free
wlock:  (66722s)

Also habe ich den folgenden Befehl ausgeführt, und damit war das Problem für mich gelöst:

hg debuglocks -W

Ich verwende Win7 und TortoiseHg 4.8.7.

Answer 2

Ich hatte das gleiche Problem unter Win 7. Die Lösung war, folgende Dateien zu entfernen:

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

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

Answer 3

Ich erwarte nicht, dass dies eine erfolgreiche Antwort ist, aber es ist eine ziemlich ungewöhnliche Situation. Ich erwähne es, falls jemand anderes als ich darauf stößt.

Heute bekam ich die Meldung "waiting for lock on repository" bei einem hg push Befehl.

Als ich den angehängten hg-Befehl beendete, konnte ich kein .hg/store/lock sehen

Als ich nach .hg/store/lock suchte, während der Befehl angehängt war, existierte es. Aber die Sperrdatei wurde gelöscht, als der hg-Befehl beendet wurde.

Als ich zum Ziel des Stoßes ging und hg pull ausführte, kein Problem.

Schließlich stellte ich fest, dass sich die Prozess-ID in der Nachricht "hg push was lock waiting" jedes Mal änderte. Es stellte sich heraus, dass "hg push" auf eine Sperre wartete, die von ihm selbst gehalten wurde (oder möglicherweise von einem Unterprozess, ich habe das nicht weiter untersucht).

Es stellte sich heraus, dass die beiden Arbeitsbereiche, nennen wir sie A und B, .hg-Bäume hatten, die durch Symlink gemeinsam genutzt wurden:

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

Das ist KEINE gute Sache, die man mit Mercurial machen sollte. Mercurial versteht das Konzept nicht, dass zwei Arbeitsbereiche das gleiche Repository teilen. Ich verstehe jedoch, dass jemand, der von einem anderen VCS zu Mercurial kommt, dies vielleicht möchte (Perforce tut dies, obwohl es kein DVCS ist; das Bazaar DVCS kann dies angeblich). Ich bin überrascht, dass ein symlinked REP-Root/.hg überhaupt funktioniert, obwohl es so scheint, außer für diesen Push.

Answer 4

Wenn das gesperrte Repo das Original war, kann ich mir nicht vorstellen, dass es Ändern von Es hat Sie also nur daran gehindert, es in der Mitte zu ändern und den Klon zu versauen. Nach dem Entfernen der Sperre sollte es wieder gehen.

Die neue geklonte Kopie (wenn es sich um einen lokalen Klon handelt) könnte sich jedoch in irgendeinem fehlerhaften Zustand befinden, so dass Sie sie wegwerfen und neu beginnen sollten. (Wenn es sich um einen entfernten Klon handelt, würde ich hoffen, dass er fehlgeschlagen ist und die unvollständige Kopie bereits verworfen wurde).

Answer 5

Ich bin auf dieses Problem unter Mac OS X 10.7.5 und Mercurial 2.6.2 gestoßen, als ich versucht habe, einen Push durchzuführen. Nach dem Upgrade auf Mercurial 3.2.1 erhielt ich die Meldung "keine Änderungen gefunden" anstelle von "warte auf Sperre des Repositorys". Ich habe herausgefunden, dass der Standardpfad irgendwie auf das gleiche Repository verweist, so dass es nicht allzu überraschend ist, dass Mercurial verwirrt ist.