Mercurial atascado "esperando bloqueo"

346

Tengo una pantalla azul en Windows mientras clonaba un repositorio mercurial.

Después de reiniciar, ahora recibo este mensaje para casi todos los comandos hg:

c: \ src \> hg commit
esperando bloqueo en el repositorio c: \ src \ McVrsServer en poder de '\ x00 \ x00 \ x00 \ x00 \ x00 \
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
interrumpido!

Google no es de ayuda.

¿Algun consejo?

mercurial jm.
fuente
3
Wow, también tuve una pantalla azul mientras cometía y obtuve el mismo error. ¡Me alegro de no ser el único!
CBarr
3
Propuse una
Karl Richter

Respuestas:

489

Cuando "espere el bloqueo en el repositorio", elimine el archivo del repositorio: .hg/wlock(o puede estar en .hg/store/lock)

Al eliminar el archivo de bloqueo, debe asegurarse de que nada más esté accediendo al repositorio. (Si el bloqueo es una cadena de ceros o en blanco, esto es casi seguro).

jm.
fuente
103
Mi problema no tenía nada que ver con la clonación o los BSOD, pero para mí eliminé el archivo .hg / wlock para limpiar el bloqueo.
Frank Hadder
32
hg recoverdebe ejecutarse después de una situación de bloqueo roto.
James Broadhead
99
Muchas gracias: después de eliminar .hg / wlock no tenía idea de cuál era el problema
Andrew Buss, el
34
En mi caso (TortoiseHg V2.9.2 con Mercurial 2.7.2), el nombre del archivo era "wlock" en lugar de "lock"; y se colocó en el directorio ".hg", no en ".hg / store".
Fernando
77
@Marmoute: el repositorio se bloquea cada vez que se va a realizar un cambio. Si algo hace que el proceso falle, es decir, un error en Mercurial, una máquina que falla, etc., los archivos de bloqueo permanecen, no se limpian. Creo que las sugerencias aquí para eliminar los archivos de bloqueo manualmente son para abordar aquellos casos en los que el repositorio de alguna manera quedó en un estado "sucio". Llamarlo "eliminar ciegamente la protección mercurial" no es una caracterización justa ni precisa de lo que está sucediendo en estos casos.
JoGusto
345

Cuando waiting for lock on working directory, eliminar .hg/wlock.

Tiago Matos
fuente
66
Este fue el caso para mí. Era un enlace simbólico en 'nix a la corriente server:pid. Gracias un montón. Luego tuve que correr $ hg recoverpara borrar el diario existente (y el mensaje de confirmación) que ctrl+cedité. No estoy seguro, pero es posible que pueda ejecutar $ hg recoversin eliminar el archivo de bloqueo y lo hará por usted. Vale la pena intentarlo, supongo.
sholsinger
2
Solo una nota para @sholsinger para decir que ejecutar hg recovery no funciona a menos que elimine el bloqueo primero. Lo intenté.
Dan
1
El repositorio se bloquea por una razón, otro proceso está trabajando en el repositorio. Debería encontrar ese proceso y finalizarlo en lugar de eliminar ciegamente la protección mercurial. Solo soltar el archivo puede provocar daños en el repositorio.
Marmoute
@Marmoute En mi caso, tuve que quitar el bloqueo, porque ningún otro proceso estaba trabajando en el repositorio. Pero estoy de acuerdo, vale la pena buscar otro proceso primero
Mi-La
Recibí este mensaje de repente cuando trataba de tirar, después de tirar y empujar durante unos días sin problemas. Después de eliminar el archivo, el problema se resolvió. El archivo tenía 0 KB, lo que significa que supongo que estaba vacío. ¿Está bien simplemente borrar el archivo? Supongo que es útil para la protección.
Ben Carp
47

Tuve este problema sin archivos de bloqueo detectables. Encontré la solución aquí: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Aquí hay una transcripción de la consola 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]

Después de esto, el tirón abortado se ejecutó con éxito.

El bloqueo se había establecido hace más de 2 años, por un proceso en una máquina que ya no está en la LAN. Vergüenza para los desarrolladores de hg por a) no documentar los bloqueos adecuadamente; b) no marcarlos en el tiempo para su eliminación automática cuando se vuelven obsoletos.

Thomas Sharpless
fuente
23
Protip: Si wlockestá encerrado, usehg debuglocks --force-wlock
Brad Turek
55
He usado tortuga hg durante más de 7 años. Nunca vi el problema hasta hace unos 3 meses. Lo he visto 3 veces en los últimos 3 meses. Alguna actualización debe haber exacerbado el problema.
D ei
20

El compañero de trabajo tuvo este problema exacto hoy, después de un BSoD mientras intentaba presionar. El tenia que:

Luego su repositorio funcionó nuevamente.

EDITAR: Según el comentario de @Marmoute: cuando se trata de problemas relacionados con el bloqueo, el uso hg debuglockes una alternativa más segura a la eliminación ciega del .hg/store/lockarchivo.

Ian Kemp
fuente
2
1) No hay absolutamente ninguna razón por la que deba tocar el archivo phaseroots, no tiene absolutamente ninguna relación con el bloqueo. 2) cegar quitar el bloqueo es una mala idea, es probable que haya otro proceso usándolo. use hg debuglock para descubrir qué está sucediendo y finalizar el proceso que mantiene el bloqueo
Marmoute
3
1) Teniendo en cuenta que eliminarlo solucionó el problema, tendría que estar en desacuerdo. 2) No sabía acerca de hg debuglock en ese momento (tampoco puedo encontrar ninguna documentación), y dado que el sistema acababa de salir de un reinicio, obviamente no había nada que bloqueara el repositorio, por lo tanto, eliminar el archivo de bloqueo era apropiado.
Ian Kemp
12

Estoy muy familiarizado con el código de bloqueo de Mercurial (a partir de 1.9.1). El consejo anterior es bueno, pero agregaría eso:

  1. He visto esto en la naturaleza, pero rara vez, y solo en máquinas con Windows.
  2. Eliminar los archivos de bloqueo es la solución más fácil, PERO debe asegurarse de que nada más esté accediendo al repositorio. (Si el bloqueo es una cadena de ceros, esto es casi seguro).

(Para los curiosos: aún no he podido detectar la causa de este problema, pero sospecho que es una versión anterior de Mercurial que accede al repositorio o un problema en la llamada socket.gethostname () de Python en ciertas versiones de Windows).

Brad O
fuente
2
FWIW me acaba de pasar en Ubuntu. Era la primera vez que usaba el repositorio en varias semanas, así que no recuerdo qué podría haberlo dejado en ese estado.
Cosmologicon
7

Tuve el mismo problema en Win 7. La solución fue eliminar los siguientes archivos:

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

En cuanto a .hg / store / lock, no había tal archivo.

Ivan Dulov
fuente
Bienvenido a Stackoverflow. Intenta agregar más contenido a la publicación
NJInamdar
55
1) No hay absolutamente ninguna razón por la que deba tocar el archivo phaseroots, no tiene absolutamente ninguna relación con el bloqueo. 2) cegar quitar el bloqueo es una mala idea, es probable que haya otro proceso usándolo. use hg debuglockpara descubrir qué está sucediendo y terminar el proceso que retiene el bloqueo.
Marmoute
6

No espero que sea una respuesta ganadora, pero es una situación bastante inusual. Mencionar en caso de que alguien que no sea yo se encuentre con él.

Hoy recibí el "esperando bloqueo en el repositorio" en un comando hg push.

Cuando maté el comando hg colgado no pude ver .hg / store / lock

Cuando busqué .hg / store / lock mientras el comando estaba colgado, existía. Pero el archivo de bloqueo se eliminó cuando se mató el comando hg.

Cuando fui al objetivo del empuje, y ejecuté hg pull, no hay problema.

Finalmente, me di cuenta de que la identificación del proceso en el hg push era un mensaje de bloqueo de espera que cambiaba cada vez. Resulta que el "empuje hg" estaba colgando esperando un bloqueo en sí mismo (o posiblemente un subproceso, no investigé más).

Resulta que las dos áreas de trabajo, llamémoslas A y B, tenían árboles .hg compartidos por enlace simbólico:

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

Esto NO es algo bueno que hacer con Mercurial. Mercurial no entiende el concepto de dos espacios de trabajo que comparten el mismo repositorio. Sin embargo, entiendo cómo alguien que viene a Mercurial desde otro VCS podría querer esto (Perforce lo hace, aunque no es un DVCS; según los informes, el Bazaar DVCS puede hacerlo). Me sorprende que un REP-ROOT / .hg con enlace simbólico funcione en absoluto, aunque parece que exceptúa este impulso.

Krazy Glew
fuente
¿HG no realiza un seguimiento de dirstate .hg/? Cuando dice que los repositorios "funcionan", si no se ejecuta hg upen uno, el directorio no está sincronizado en el otro, ¿o mercurial hace algo especial para respaldar esto?
binki
1
Puede usar la extensión de compartir (enviada con Core Mercurial) para tener múltiples directorios de trabajo desde un único repositorio.
Marmoute
4

Yo tuve el mismo problema. Recibí el siguiente mensaje cuando intenté confirmar:

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

hg debuglock mostró esto:

lock:  free
wlock:  (66722s)

Entonces hice el siguiente comando, y eso solucionó el problema para mí:

hg debuglocks -W

Usando Win7 y TortoiseHg 4.8.7.

usuario10125940
fuente
2

Si el repositorio bloqueado era el original, no puedo imaginar que se estuviera modificando para clonarlo, por lo que solo evitaba que lo cambiara en el medio y arruinara el clon. Debería estar bien después de quitar la cerradura.

Sin embargo, la nueva copia clonada (si se tratara de un clon local) podría estar en cualquier tipo de estado malformado, por lo que debe tirarla y comenzar de nuevo. (Si se tratara de un clon remoto, espero que haya fallado y ya haya arrojado la copia incompleta).

Markpasc
fuente
2

Encontré este problema en Mac OS X 10.7.5 y Mercurial 2.6.2 al intentar presionar. Después de actualizar a Mercurial 3.2.1, recibí "no se encontraron cambios" en lugar de "esperar el bloqueo en el repositorio". Descubrí que de alguna manera la ruta predeterminada se había configurado para apuntar al mismo repositorio, por lo que no es demasiado sorprendente que Mercurial se confunda.

JWWalker
fuente
1
Descubrí que de alguna manera la ruta predeterminada se había configurado para apuntar al mismo repositorio . Esta. Gracias, hice loops para deshacerme del problema y el pathentorno fue el culpable.
WoJ