Mercurial bloccato “in attesa del blocco”

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

  •  08-06-2019
  •  | 
  •  

Domanda

Ho visualizzato una schermata blu in Windows durante la clonazione di un repository Mercurial.

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

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 non è d'aiuto.

Qualche consiglio?

È stato utile?

Soluzione

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

Quando elimini il file di blocco, devi assicurarti che nient'altro stia accedendo al repository.(Se il lucchetto è una stringa di zeri o uno spazio vuoto, questo è quasi certamente vero).

Altri suggerimenti

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

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

Successivamente il pull interrotto è stato eseguito con successo.

Il blocco è stato impostato più di 2 anni fa, tramite un processo su una macchina che non si trova più sulla LAN.Vergogna agli sviluppatori di hg per a) non aver documentato adeguatamente i blocchi;b) non contrassegnarli con la data e l'ora per la rimozione automatica quando diventano obsoleti.

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

Quindi il suo repository ha funzionato di nuovo.

MODIFICARE: Secondo il commento di @Marmoute, quando si affrontano problemi relativi al blocco, utilizzando hg debuglock è un'alternativa più sicura all'eliminazione cieca del file .hg/store/lock file.

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

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

(Per i curiosi:Non sono ancora riuscito a individuare la causa di questo problema, ma sospetto che si tratti di una versione precedente di Mercurial che accede al repository o di un problema nella chiamata socket.gethostname() di Python su alcune versioni di Windows.)

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

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

Per quanto riguarda .hg/store/lock, non esisteva un file del genere.

Non mi aspetto che questa sia una risposta vincente, ma è una situazione abbastanza insolita.Menzionarlo nel caso in cui qualcuno diverso da me si imbattesse in esso.

Oggi ho ricevuto il messaggio "in attesa del blocco sul repository" su un comando hg push.

Quando ho terminato il comando hg bloccato non sono riuscito a vedere .hg/store/lock

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

Quando sono andato al bersaglio del push ed ho eseguito hg pull, nessun problema.

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

Si scopre che i due spazi di lavoro, chiamiamoli A e B, avevano alberi .hg condivisi tramite collegamento simbolico:

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

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

Se il repository bloccato fosse l'originale, non riesco a immaginare che lo fosse modificando per clonarlo, quindi ti impediva solo di cambiarlo a metà e di rovinare il clone.Dovrebbe andare bene dopo aver rimosso il lucchetto.

Tuttavia, la nuova copia clonata (se fosse un clone locale) potrebbe trovarsi in qualsiasi tipo di stato non valido, quindi dovresti eliminarla e ricominciare da capo.(Se fosse un clone remoto, spero che abbia fallito e abbia già eliminato la copia incompleta.)

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 ricevuto "nessuna modifica trovata" invece di "in attesa del blocco del repository".Ho scoperto che in qualche modo il percorso predefinito era stato impostato per puntare allo stesso repository, quindi non sorprende troppo che Mercurial si confonda.

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'utilizzo del percorso UNC anziché della lettera di unità sembra eludere il problema.

Ho avuto lo stesso problema.Ho ricevuto il seguente messaggio quando ho provato a impegnarmi:in attesa del blocco sulla directory di lavoro tenuta da ''

hg debuglock ha mostrato questo:serratura:wlock gratuito:(66722)

Quindi ho eseguito il seguente comando e questo ha risolto il problema per me:hg debuglock -W

Utilizzando Win7 e TortoizeHg 4.8.7.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top