gancho Mercurial no ejecutar correctamente

Question

Esto debería ser una cosa muy simple de haber corrido, pero por alguna razón no va a funcionar con mi repositorio de Mercurial. Todo lo que quiero es el repositorio remoto para ejecutarse automáticamente cada vez que alguien hg update empuja a ella. Así que tengo esto en mi archivo .hg / hgrc:

[hook]
changegroup = hg update

simple, ¿verdad? Pero por alguna razón, esto no se ejecuta. También intenté escribir un script de shell que hizo esto. .hg / hgrc veía así:

[hooks]
changegroup = /home/marc/bin/hg-update

y hg-actualización se veía así:

#!/bin/sh
hg help >> /home/marc/works.txt;
hg update >> /home/marc/works.txt;
exit 0;

Pero, de nuevo, esto no se actualiza. El contenido de hg help se escriben en works.txt, pero no hay nada escrito por -v. ¿Hay algo obvio que me falta aquí? Esto me ha estado plagando durante días y yo sólo parece que no puede conseguir que funcione.

Actualizar

Bueno por lo que de nuevo, usando el echo interruptor en la línea de comandos desde mi estación de trabajo empujando al repositorio remoto no imprime ningún mensajes detallados, incluso cuando tengo esos .hg/hgrc líneas en <=>. Sin embargo, cuando hago un empujón de un clon de la cesión temporal en el mismo sistema de ficheros (estoy conectado a través de SSH), esto es lo que me sale:

bash-3.00$ hg -v push ../test-repo/
pushing to ../test-repo/
searching for changes
1 changesets found
running hook prechangegroup: echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
Remote repo is at 821:1f2656753c98
Remote repo wdir is at 821:1f2656753c98
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
running hook changegroup: echo "Updating.... `hg update -v`"
echo "Remote repo is at `hg tip -q`"
echo "Remote repo wdir is at `hg parents -q`"
Updating.... resolving manifests
getting license.txt
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Remote repo is at 822:389a6c7276c6
Remote repo wdir is at 822:389a6c7276c6

Así funciona, pero de nuevo sólo cuando empujo desde el mismo sistema de ficheros. No funciona si trato de empujar al repositorio desde otra estación de trabajo en la red.

Answer 1

pasé algún tiempo investigando esto por mí mismo. Creo que la respuesta al problema se describe de forma concisa aquí :

  

La salida tiene que ser redirigido a stderr (o / dev / null), porque stdout   se utiliza para el flujo de datos.

Básicamente, usted no está redirigiendo a stderr, y por lo tanto la salida estándar contaminantes.

Answer 2

Bueno, después de pasar por los mismos pasos de frustración como lo hizo Marc W hace un tiempo, finalmente encontré la solución al problema, al menos cuando la porción remota se realiza con el guión hgwebdir WSGI.

Me di cuenta de que cuando se utiliza este tipo de pulsador remoto a través de HTTP o HTTPS, Mercurial simplemente ignora todo lo que escribe en el archivo .hg / hgrc o su repositorio. Sin embargo, entrar en el gancho en el hgwebdir config hace el truco.

Así que si la línea de fondo en su hgwebdir.wsgi guión es algo así como

application = hgwebdir('hgweb.config')

la [ganchos] sección de configuración tiene que ir a la mencionada hgweb.config .

Un inconveniente es que estos ganchos se ejecutan para cada repositorio enumerado en la sección [caminos] de que config. A pesar de que HG ofrece otra función WSGI con capacidad (hgweb en lugar de hgwebdir) para servir a un solo repositorio, que uno no parece apoyar ningún gancho (tampoco tiene ninguna configuración). Esto puede, sin embargo, ser evitado mediante el uso de un hgwebdir como se describe anteriormente y que tiene algunos Apache RewriteRule mapa todo en el subdirectorio deseado. Esta funciona para mí:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/reponame
RewriteRule ^(.*)$ reponame/$2 [QSA]

Disfrute con sus ganchos remotos a través de HTTP: D

Answer 3

En primer lugar, quiero corregir algunos comentarios anteriores.

• Los ganchos se invoca también al empujar sobre el sistema de archivos.
• No es necesario para mantener el gancho en el repositorio en el que desea que les permite operar. También puede escribir el mismo gancho que en su pregunta en el extremo del usuario. Usted tiene que cambiar el evento de changegroup al saliente y también para especificar la URL de recompra a distancia con el interruptor -R. A continuación, si el usuario tiene privilegios suficientes empujando en el repositorio remoto, el gancho se ejecutará con éxito.

.hg / hgrc

[hooks]
outgoing = hg update -R $HG_URL

Ahora hacia su problema .... Sugiero crear dos ganchos prechangegroup y changegroup y la impresión de una cierta salida de depuración.

.hg / hgrc

[hooks]
prechangegroup = echo "Remote repo is at `hg tip -q`"
                 echo "Remote repo wdir is at `hg parents -q`"
changegroup    = echo "Updating.... `hg update -v`"
                 echo "Remote repo is at `hg tip -q`"
                 echo "Remote repo wdir is at `hg parents -q`"

Y también empujar con el conmutador -v, de modo que usted puede saber lo que el gancho se está ejecutando. Si todavía no se puede averiguar, publicar la salida. Podría ser capaz de ayudar.

Answer 4

Mi problema era que mi solicitud hgwebdir corrió como el usuario "hg", pero el repositorio fue propiedad de mí, así que tuve que añadir en este poco de config para hgweb.config a conseguir que se ejecute el gancho:

[trusted]
users = me

Answer 5

Es necesario tener en el remoto hgrc de repositiory. Suena como si es en tu repositorio local.

Edit: También depende de cómo lo está empujando. Algunos métodos no invocan ganchos en el lado derecho. (SSH hace, creo que hace HTTP, sistema de archivos hace no )

Edit2: ¿Qué pasa si se pulsa "localmente" en la computadora del repo remoto. Es posible tener diferentes usuarios / permisos entre el servidor web y el hgrc-archivo. (Véase [servidor] y las Directivas de confianza para hgrc.)

Answer 6

Yo tenía el mismo problema que empuja desde Windows Eclipse a través de http, pero después de capturar stderr, encontré que era necesaria la ruta completa al archivo hg.bat. Mi sección de ganchos ahora se ve así:

[hooks]
incoming = c:\Python27\Scripts\hg.bat update > hg_log.txt 2>>hg_err.txt

Espero que esto ayude a alguien más.   SteveT

Answer 7

Trate encender gancho de depuración para ver por qué no se está ejecutando.

Probablemente un problema de permisos o algo por el estilo.

Answer 8

tomó un tiempo, pero tengo trabajo.

Empecé con

[hooks]
tag=set >&2
commit=set >&2

la> & 2 tubos de TI a error estándar de modo consolas remotas lo mostrarán.

cuando el telecontrol esta debe ser la salida en la consola si se está ejecutando

hg push https://host/hg   -v

No fue.

I estaba usando hgweb.cgi así que cambió a hgweb.wsgi con ninguna diferencia.

lo que he descubierto es que algunos ganchos no se les llama en el control remoto.

cuando me cambié a

[hooks]
incoming= set >&2

la etiqueta de ganchos y comprometerse no parecen ser llamado, pero de entrada y de cambios se hacen la llama. No he confirmado los otros.

ahora que lo tengo trabajo Cambié de nuevo a hgweb.cgi y todo funciona de la misma.

Answer 9

Lla razón por la que he encontrado para esto no tiene nada que ver con la reorientación de stdout a stderr. Como se puede ver en la página wiki no se especifica en la versión actual del wiki https: //www.mercurial -scm.org/wiki/FAQ#FAQ.2FCommonProblems.Any_way_to_.27hg_push.27_and_have_an_automatic_.27hg_update.27_on_the_remote_server.3F

El problema que he encontrado es de alrededor de permisos .

En mi configuración original, que tenía un usuario, digamos hguser con un acuerdo de recompra en su casa, y una secuencia de comandos para lanzar /etc/init.d/hg.init hg serve. El problema que se root estaba siendo dirigido por chown, mientras que la mayoría de los archivos bajo el repositorio se referían a chown -R hguser:hguser /home/hguser/repo (algunos de ellos cambiaron a su hguser -c "hg serve ..." en algún momento, pero no le importa, ya que voy a corregir con changegroup = hg update -C)

Solución:

• [hooks] (para corregir todos los archivos, volver a hguser)
• repo/.hg/hgrc lanzamiento (en mi caso de push)
• hg update -C -r staging bajo tip en development como de costumbre

Ahora que debería funcionar en hg.init

PD: en mi caso, en lugar de actualizar a la cabeza de una rama específica, así que uso su hguser, para realizar la actualización del servidor de transición sólo a la cabeza de la rama previsto, incluso si el <=> es de otra rama (como <=> por ejemplo)

Por cierto mi <=> guión terminó así: (nótese la parte <=>)

#!/bin/sh
#
# Startup script for mercurial server.
#
# @see http://jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html

HG=/usr/bin/hg
CONF=/etc/mercurial/hgweb.config
# Path to PID file of running mercurial process.
PID_FILE=/etc/mercurial/hg.pid

state=$1

case "$state" in
'start')
    echo "Mecurial Server service starting."
    (su hguser -c "${HG} serve -d --webdir-conf ${CONF} -p 8000 --pid-file ${PID_FILE}")
  ;;

'stop')
  if [ -f "${PID_FILE}" ]; then
    PID=`cat "${PID_FILE}"`
    if [ "${PID}" -gt 1 ]; then
      kill -TERM ${PID}
      echo "Stopping the Mercurial service PID=${PID}."
    else
      echo Bad PID for Mercurial -- \"${PID}\"
    fi
  else

    echo No PID file recorded for mercurial
  fi
  ;;

*)
  echo "$0 {start|stop}"
  exit 1
  ;;
esac

PD: el crédito debido a http : //jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html