Mercurial atascado " esperando la cerradura"

Cuando waiting for lock on working directory, suprímase .hg/wlock.

Tuve este problema con ningún archivo de bloqueo detectable. He encontrado la solución aquí: http://schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

Aquí está 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 intento abortado corrió 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 adecuadamente los bloqueos; b) no marcarlos retiro automático cuando consiguen rancios.

Compañero de trabajo tenía este problema exacto hoy, después de un BSoD mientras trataba de empujar. Tenía que:

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

Entonces su repositorio funcionó de nuevo.

EDITAR: Según el comentario de @Marmoute: cuando se trata de problemas relacionados con bloqueos, usar hg debuglock es una alternativa más segura para eliminar ciegamente el archivo .hg/store/lock.

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

1. He visto esto en la naturaleza, pero rara vez, y solo en máquinas Windows.
2. Eliminar 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 candado es una cadena de ceros, esto es casi seguro que es cierto).

(Para los curiosos: Todavía no he podido detectar la causa de este problema, pero sospecho que es ya sea una versión anterior de Mercurial accediendo al repositorio o un problema en el socket de Python.gethostname () llama a ciertas versiones de Windows.)

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

Hoy tengo el "esperando bloqueo en el repositorio" en un comando push de hg.

Cuando maté al comando Hung hg pude ver que no .hg/store / lock

Cuando busqué .hg / store / lock mientras el comando estaba colgado, existía. Pero el archivo de bloqueo fue eliminado cuando el comando hg fue asesinado.

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

Finalmente me di cuenta de que el ID del proceso en el mensaje de espera de bloqueo de hg estaba cambiando cada vez. Resulta que el "empuje de hg" estaba colgando a la espera de una cerradura sostenida por sí mismo (o posiblemente un subproceso, no investigué más).

Resulta que los dos espacios de trabajo, llamémoslos A y B, tenían .árboles de hg compartidos por symlink:

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

Esto no es algo bueno que hacer con Mercurial. Mercurial no entiende la concepto de dos espacios de trabajo que comparten el mismo repositorio. Entiendo, sin embargo, cómo alguien que viene a Mercurial desde otro VCS podría querer esto (Forzosamente lo hace, aunque no es un DVCS; los DVCS de Bazaar, según se informa, pueden hacerlo). Me sorprende que un enlace simbólico REP-ROOT/.hg funciona en absoluto, aunque parece que a excepción de este empuje.

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.

Si el bloqueo de repo es el original, no me puedo imaginar que era modificar es clonarlo, así que era sólo le impide modificar en el centro y echar a perder el clon. Debe estar bien después de quitar la cerradura.

La nueva copia clonada (si se trata de un clon local) podría estar en cualquier tipo de estado malformado, sin embargo, por lo que debe desecharla y volver a iniciarla. (Si fuera un clon remoto, esperaría que fallara y ya tirara la copia incompleta.)

Si solo sucede en unidades asignadas, 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.

Me encontré con este problema en Mac OS X 10.7.5 y Mercurial 2.6.2 al intentar empujar. Después de actualizar a Mercurial 3.2.1, obtuve " no changes found "en lugar de"waiting for lock on repository". Descubrí que de alguna manera la ruta predeterminada se había establecido para apuntar al mismo repositorio, por lo que no es demasiado sorprendente que Mercurial se confundiera.

Yo tenía el mismo problema. Recibí el siguiente mensaje cuando trided to commit: esperando bloqueo en el directorio de trabajo de en poder de "

Hg debuglock mostrar esto: bloqueo: gratis wlock: (66722s)

Así que hice el siguiente comando, y eso solucionó el problema para mí: hg debuglocks-W

Usando Win7 y TortoizeHg 4.8.7.