Mercurial atascado "esperando bloqueo"

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?

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).

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

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.

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

• eliminar el archivo .hg/store/lock(según la respuesta aceptada )
• eliminar el archivo .hg/store/phaseroots(según este informe de error de TortoiseHG )

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.

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).

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.

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.

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.

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).

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.

Si solo ocurre en unidades mapeadas, podría ser un error https://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-share . El uso de la ruta UNC en lugar de la letra de la unidad parece evitar el problema.