Mercurial atascado “esperando bloqueo”

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

  •  08-06-2019
  •  | 
  •  

Pregunta

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

Después de reiniciar, recibo este mensaje para casi todos los comandos 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 no es de ayuda.

¿Algun consejo?

¿Fue útil?

Solución

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

Al eliminar el archivo de bloqueo, debe asegurarse de que nada más acceda al repositorio.(Si el candado es una cadena de ceros o un espacio en blanco, es casi seguro que esto sea cierto).

Otros consejos

Cuando waiting for lock on working directory, borrar .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, la extracción abortada se ejecutó con éxito.

El bloqueo se estableció hace más de 2 años mediante un proceso en una máquina que ya no está en la LAN.Qué vergüenza para los desarrolladores de hg por a) no documentar los bloqueos adecuadamente;b) no ponerles una marca de tiempo para su eliminación automática cuando se vuelven obsoletos.

Un compañero de trabajo tuvo exactamente este problema hoy, después de un BSoD al intentar pujar.El tenia que:

Luego su repositorio volvió a funcionar.

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

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 que:

  1. He visto esto en la naturaleza, pero rara vez, y solo en máquinas con Windows.
  2. Eliminar archivos bloqueados es la solución más sencilla, PERO debes asegurarte de que nada más acceda al repositorio.(Si el candado es una cadena de ceros, es casi seguro que esto sea cierto).

(Para los curiosos:Todavía 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 existía tal archivo.

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

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

Cuando eliminé el comando hung hg 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 eliminó el comando hg.

Cuando fui al objetivo del empujón y ejecuté hg pull, no hubo problema.

Finalmente, me di cuenta de que el ID del proceso en hg push era el mensaje de bloqueo en espera que cambiaba cada vez.Resulta que el "hg push" estaba colgado esperando un bloqueo que se mantuviera solo (o posiblemente un subproceso, no investigué más).

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

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

Esto NO es bueno hacer con Mercurial.Mercurial no comprende el concepto de dos espacios de trabajo que comparten el mismo repositorio.Entiendo, sin embargo, cómo alguien que llega a Mercurial desde otro VCS podría querer esto (Perforce sí, aunque no es un DVCS;(según se informa, Bazaar DVCS puede hacerlo).Me sorprende que un enlace simbólico REP-ROOT/.hg funcione, aunque parece que no es así por este impulso.

Si el repositorio bloqueado era el original, no puedo imaginar que fuera modificando clonarlo, por lo que solo te impedía cambiarlo en el medio y estropear el clon.Debería estar bien después de quitar el candado.

Sin embargo, la nueva copia clonada (si fuera un clon local) podría tener algún tipo de formato incorrecto, por lo que deberías desecharla y empezar de nuevo.(Si fuera un clon remoto, esperaría que fallara y ya desechara 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 "esperando a que se bloquee el repositorio".Descubrí que de alguna manera la ruta predeterminada se había configurado para apuntar al mismo repositorio, por lo que no es sorprendente que Mercurial se confunda.

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

Yo tuve el mismo problema.Recibí el siguiente mensaje cuando intenté comprometerme:esperando bloqueo en el directorio de trabajo retenido por ''

hg debuglock mostró esto:cerrar con llave:WLOCK GRATIS:(66722s)

Entonces hice el siguiente comando y eso me solucionó el problema:bloqueos de depuración hg -W

Usando Win7 y TortoizeHg 4.8.7.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top