Mercurial bloccato "in attesa di blocco"

346

Ha ottenuto uno schermo blu in Windows durante la clonazione di un repository mercuriale.

Dopo il riavvio, ora ricevo questo messaggio per quasi tutti i comandi hg:

c: \ src \> hg commit
in attesa di blocco sul repository c: \ src \ McVrsServer tenuto da '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00'
! interrotto

Google non è di aiuto.

Qualche consiglio?

mercurial

— jm.
fonte

3

Wow, ho anche avuto uno schermo blu mentre commettevo e ho avuto lo stesso errore. Sono contento di non essere l'unico!

— CBarr,

3

Ho proposto un feedback migliore del messaggio di errore su bz.selenic.com/show_bug.cgi?id=4752

— Karl Richter,

489

Quando "in attesa di blocco sul repository", elimina il file repository: .hg/wlock(o potrebbe essere in .hg/store/lock)

Quando si elimina il file di blocco, è necessario assicurarsi che nient'altro acceda al repository. (Se il blocco è una stringa di zeri o vuoto, questo è quasi certamente vero).

— jm.
fonte

103

Il mio problema non aveva nulla a che fare con la clonazione o con BSOD, ma per me ho eliminato il file .hg / wlock per cancellare il blocco.

— Frank Hadder,

32

hg recoverdovrebbe essere eseguito dopo una situazione di blocco interrotta.

— James Broadhead,

9

Mille grazie - dopo aver rimosso .hg / wlock non avevo idea di quale fosse il problema

— Andrew Buss

34

Nel mio caso (TortoiseHg V2.9.2 con Mercurial 2.7.2), il nome del file era "wlock" anziché "lock"; ed è stato inserito nella directory ".hg", non in ".hg / store".

— Fernando,

7

@Marmoute: il repository viene bloccato ogni volta che verrà apportata una modifica. Se qualcosa fa fallire quel processo - ovvero, un bug in Mercurial, una macchina che va in crash, ecc. - i file di blocco rimangono, non ripuliti. Credo che i suggerimenti qui per eliminare manualmente i file di blocco siano quelli per i casi in cui il repository è stato in qualche modo lasciato in uno stato "impuro". Chiamarlo "rimuovere ciecamente la protezione mercuriale" non è una caratterizzazione giusta né accurata di ciò che sta accadendo in questi casi.

— JoGusto,

345

Quando waiting for lock on working directory, cancella .hg/wlock.

— Tiago Matos
fonte

6

Questo è stato il caso per me. Era un collegamento simbolico su 'nix alla corrente server:pid. Grazie mille. Quindi ho dovuto correre $ hg recoverper cancellare il diario esistente (e il messaggio di commit) che ho ctrl+ceditato. Non sono sicuro, ma potresti essere in grado di eseguire $ hg recoversenza eliminare il file di blocco e lo farà per te. Vale la pena provare.

— Sholsinger,

2

Solo una nota per @sholsinger per dire che l'esecuzione di hg recovery non funziona se non si rimuove prima il blocco. L'ho provato.

— Dan,

1

Il repository viene bloccato per un motivo, un altro processo sta lavorando sul repository. Dovresti trovare quel processo e interromperlo invece di rimuovere ciecamente la protezione mercuriale. Il semplice rilascio del file può portare alla corruzione del repository.

— Marmoute,

@Marmoute Nel mio caso ho dovuto rimuovere il blocco, perché nessun altro processo stava funzionando sul repository. Ma sono d'accordo, vale la pena cercare prima un altro processo

— Mi-La,

Ho ricevuto questo messaggio improvvisamente quando ho provato a tirare, dopo aver tirato e spinto per alcuni giorni senza problemi. Dopo aver eliminato il file, il problema è stato risolto. Il file era di 0 KB, il che significa che suppongo fosse vuoto. Va bene semplicemente eliminare il file? Immagino sia utile per la protezione.

— Ben Carp

47

Ho avuto questo problema senza file di blocco rilevabili. Ho trovato la soluzione qui: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Ecco una trascrizione dalla console di 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]

Dopo questo il tiro interrotto è andato a buon fine.

Il blocco era stato impostato più di 2 anni fa, mediante un processo su una macchina che non si trova più sulla LAN. Peccato per gli sviluppatori hg per a) non documentare adeguatamente i blocchi; b) non timestamp per la rimozione automatica quando diventano stantii.

— Thomas Sharpless
fonte

23

Protip: se wlockè quello bloccato, utilizzarehg debuglocks --force-wlock

— Brad Turek il

5

Ho usato tartaruga hg per 7+ anni. Non ho mai visto il problema fino a circa 3 mesi fa. L'ho visto 3 volte negli ultimi 3 mesi. Alcuni aggiornamenti devono aver esacerbato il problema.

— d Ei

20

Il collega ha avuto questo esatto problema oggi, dopo un BSoD mentre cercava di spingere. Doveva:

elimina il file .hg/store/lock(secondo la risposta accettata )
elimina il file .hg/store/phaseroots(come da questo rapporto sui bug di TortoiseHG )

Quindi il suo repository ha funzionato di nuovo.

EDIT: Secondo il commento di @ Marmoute - quando si affrontano i problemi relativi al blocco, l'utilizzo hg debuglockè un'alternativa più sicura all'eliminazione cieca del .hg/store/lockfile.

— Ian Kemp
fonte

2

1) Non c'è assolutamente alcun motivo per cui dovresti toccare il file phaseroots, è assolutamente estraneo al blocco. 2) accecare la rimozione del blocco è una cattiva idea, è probabile che ci sia un altro processo che lo utilizza. usa hg debuglock per capire cosa sta succedendo e termina il processo tenendo premuto il lucchetto

— Marmoute,

3

1) Considerando che rimuoverlo risolto il problema, dovrei essere in disaccordo. 2) All'epoca non conoscevo il debuglock di hg (non è possibile trovare alcuna documentazione su di esso), e poiché il sistema era appena uscito da un riavvio, ovviamente non c'era nulla che bloccasse il repository - quindi l'eliminazione del file di blocco era appropriata.

— Ian Kemp,

12

Conosco molto bene il codice di blocco di Mercurial (a partire dall'1.9.1). Il consiglio sopra è buono, ma aggiungerei che:

L'ho visto in natura, ma raramente e solo su macchine Windows.
L'eliminazione dei file di blocco è la soluzione più semplice, MA devi assicurarti che nient'altro acceda al repository. (Se il blocco è una stringa di zeri, questo è quasi certamente vero).

(Per i curiosi: non sono ancora stato in grado di rilevare la causa di questo problema, ma sospetto che sia una versione precedente di Mercurial che accede al repository o un problema nella chiamata socket.gethostname () di Python su alcune versioni di Windows.)

— Brad O
fonte

2

FWIW mi è appena successo su Ubuntu. Era la prima volta che utilizzavo il repository da diverse settimane, quindi non ricordo cosa avrebbe potuto lasciarlo in quello stato.

— Cosmologicon,

7

Ho avuto lo stesso problema su Win 7. La soluzione era rimuovere i seguenti file:

.hg / store / phaseroots
.hg / wlock

Per quanto riguarda .hg / store / lock - non esisteva tale file.

— Ivan Dulov
fonte

Benvenuto in StackOverflow. Prova ad aggiungere più contenuti al post

— NJInamdar

5

1) Non c'è assolutamente alcun motivo per cui dovresti toccare il file phaseroots, è assolutamente estraneo al blocco. 2) accecare la rimozione del blocco è una cattiva idea, è probabile che ci sia un altro processo che lo utilizza. usare hg debuglockper capire cosa sta succedendo e terminare il processo tenendo il blocco.

— Marmoute,

6

Non mi aspetto che questa sia una risposta vincente, ma è una situazione abbastanza insolita. Menzionando nel caso in cui qualcuno diverso da me lo incontri.

Oggi ho ricevuto "in attesa di blocco sul repository" su un comando hg push.

Quando ho ucciso il comando hung hg non riuscivo a vedere nessun .hg / store / lock

Quando ho cercato .hg / store / lock mentre il comando era bloccato, esisteva. Ma il file di blocco è stato eliminato quando il comando hg è stato ucciso.

Quando sono andato al bersaglio della spinta e ho eseguito hg pull, nessun problema.

Alla fine mi sono reso conto che l'ID del processo sul push hg era il messaggio di attesa in attesa cambiava ogni volta. Si scopre che la "spinta hg" era sospesa in attesa di un blocco tenuto da solo (o forse un sottoprocesso, non ho indagato ulteriormente).

Si scopre che le due aree di lavoro, chiamiamole A e B, avevano alberi .hg condivisi da symlink:

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

Questa NON è una buona cosa da fare con Mercurial. Mercurial non comprende il concetto di due aree di lavoro che condividono lo stesso repository. Capisco, tuttavia, come qualcuno che arriva a Mercurial da un altro VCS potrebbe volerlo (Perforce lo fa, anche se non un DVCS; secondo quanto riferito, il DVCS di Bazaar può farlo). Sono sorpreso che un REP-ROOT / .hg con collegamento simbolico funzioni affatto, anche se sembra fare eccezione per questa spinta.

— Krazy Glew
fonte

Hg track dirstate in .hg/? Quando dici che i repository "funzionano", non è possibile che l'esecuzione hg upin uno metta il dirstate fuori sincrono nell'altro, oppure Mercurial fa qualcosa di speciale per supportare questo?

— binki,

1

È possibile utilizzare l'estensione di condivisione (fornita con Core Mercurial) per avere più directory di lavoro da un singolo repository.

— Marmoute,

4

Ho avuto lo stesso problema. Ho ricevuto il seguente messaggio quando ho provato a eseguire il commit:

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

hg debuglock ha mostrato questo:

lock:  free
wlock:  (66722s)

Quindi ho fatto il seguente comando e questo ha risolto il problema per me:

hg debuglocks -W

Utilizzo di Win7 e TortoiseHg 4.8.7.

— user10125940
fonte

2

Se il repository bloccato era l'originale, non riesco a immaginare che lo stesse modificando per clonarlo, quindi ti impediva solo di cambiarlo nel mezzo e rovinare il clone. Dovrebbe andare bene dopo aver rimosso il blocco.

La nuova copia clonata (se fosse un clone locale) potrebbe trovarsi in qualsiasi tipo di stato non valido, quindi, dovresti buttarla fuori e ricominciare da capo. (Se fosse un clone remoto, spero che fallisca e abbia già buttato via la copia incompleta.)

— markpasc
fonte

2

Ho riscontrato questo problema su Mac OS X 10.7.5 e Mercurial 2.6.2 durante il tentativo di push. Dopo l'aggiornamento a Mercurial 3.2.1, ho ottenuto "nessuna modifica trovata" invece di "in attesa di blocco sul repository". Ho scoperto che in qualche modo il percorso predefinito era stato impostato in modo da puntare allo stesso repository, quindi non è sorprendente che Mercurial si confondesse.

— JWWalker
fonte

1

Ho scoperto che in qualche modo il percorso predefinito era stato impostato in modo da puntare allo stesso repository . Questo. Grazie, ho fatto un giro per eliminare il problema e l' pathambientazione era il colpevole.

— WoJ,

1

Se si verifica solo su unità mappate, potrebbe trattarsi di un bug https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . L'uso del percorso UNC anziché della lettera di unità sembra eludere il problema.

— Wilkie opaco
fonte