significado precio nike meaning mercurial

precio - Mercurial atascado "esperando bloqueo"



mercurial svn (11)

Consiguió 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 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?

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

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

Entonces su repo funcionó de nuevo.

EDITAR: De acuerdo con el comentario de @Marmoute, cuando se trata de problemas relacionados con el bloqueo, usar hg debuglock es una alternativa más segura a la eliminación ciega del .hg/store/lock .

Encontré este problema en Mac OS X 10.7.5 y Mercurial 2.6.2 cuando intentaba presionar. Después de actualizar a Mercurial 3.2.1, obtuve "no se encontraron cambios" en lugar de "esperando el bloqueo en el repositorio". Descubrí que, de algún modo, la ruta predeterminada se había configurado para apuntar al mismo repositorio, por lo que no es sorprendente que Mercurial se confundiera.

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 los archivos de bloqueo es la solución más fácil, PERO debe asegurarse de que no haya nada más que acceda al repositorio. (Si el bloqueo es una cadena de ceros, esto es casi seguro).

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

No espero que esta sea una respuesta ganadora, pero es una situación bastante inusual. Mencionando en caso de que alguien más que yo se tope con eso.

Hoy obtuve el mensaje "esperando el 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 eliminó el comando hg.

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

Finalmente, me di cuenta de que el ID de proceso en el mensaje de espera de bloqueo de hg estaba cambiando cada vez. Resulta que el "empuje de hg" estaba colgando esperando un candado sostenido 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 .hg compartidos por enlace simbólico:

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

Esto NO es una buena cosa 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 de otro VCS puede querer esto (Perforce lo hace, aunque no es un DVCS; el Bazaar DVCS puede hacerlo). Estoy sorprendido de que un REP-ROOT / .hg con enlaces simbólicos funcione, aunque parece que a excepción de este empuje.

Si el repositorio bloqueado era el original, no puedo imaginar que lo estuviera modificando para clonarlo, así que solo le impedía cambiarlo en el medio y arruinar 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 estado de formato incorrecto, por lo que debe desecharlo y volver a empezar. (Si se tratara de un clon remoto, espero que haya fallado y que ya haya tirado la copia incompleta).

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.

Tuve este problema con ningún archivo de bloqueo detectable. 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 corrió con éxito.

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

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

hg debuglock showd this: lock: free wlock: (66722s)

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

Utilizando Win7 y TortoizeHg 4.8.7.

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

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, esto es casi seguro).