hook Mercurial non eseguire correttamente

Question

Questa dovrebbe essere una cosa molto semplice da avere eseguito, ma per qualche motivo non funziona con il mio repository Mercurial. Tutto quello che voglio è per il repo remoto per eseguire automaticamente hg update ogni volta che qualcuno spinge ad esso. Così ho questo nel mio file .hg / hgrc:

[hook]
changegroup = hg update

Semplice, no? Ma per qualche ragione, questo non è mai eseguito. Ho anche provato a scrivere uno script di shell che ha fatto questo. .hg / hgrc si presentava così:

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

e HG-update si presentava così:

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

Ma ancora una volta, questo non aggiorna. Il contenuto di hg help sono scritti a works.txt, ma nulla è scritto per -v. C'è qualcosa di ovvio che mi manca qui? Questo mi ha affligge da giorni e io non riesco a farlo funzionare.

Aggiorna

Va bene così ancora una volta, utilizzando l'interruttore echo sulla riga di comando dalla mia postazione di lavoro a spingere per il repo remoto non viene stampato alcun messaggio dettagliati anche quando ho quei .hg/hgrc linee in <=>. Tuttavia, quando faccio una spinta da un clone del pronti contro termine sullo stesso file system (ho effettuato l'accesso via SSH), questo è quello che ottengo:

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

Così funziona, ma ancora una volta solo quando spingo dallo stesso file system. Non funziona se provo a spingere per il pronti contro termine da un'altra workstation in rete.

Answer 1

Ho trascorso qualche tempo alla ricerca di questo me stesso. Penso che la risposta al problema è descritto in modo conciso qui :

  

uscita deve essere reindirizzato a stderr (o / dev / null), perché stdout   viene utilizzato per il flusso di dati.

In sostanza, non si sta reindirizzando a stderr, e quindi inquinanti stdout.

Answer 2

Bene, dopo aver attraversato le stesse fasi di frustrazione come ha fatto Marc W qualche tempo fa, ho finalmente trovato la soluzione al problema, almeno quando serve a distanza è fatto con lo script hgwebdir WSGI.

ho scoperto che quando si utilizza questo tipo di spinta remoto via HTTP o HTTPS, Mercurial ignora semplicemente tutto ciò che si scrive nel file .hg / hgrc o la vostra repository. Tuttavia, inserendo il gancio nel hgwebdir config fa il trucco.

Quindi, se la linea di fondo nel vostro hgwebdir.wsgi di script è qualcosa di simile

application = hgwebdir('hgweb.config')

il [ami] sezione di configurazione ha la necessità di entrare nel citato hgweb.config .

Uno svantaggio è che questi ganci vengono eseguite per ogni repository elencato nella sezione [percorsi] di tale configurazione. Anche se HG offre un'altra funzione WSGI compatibile (hgweb anziché hgwebdir) per servire solo un singolo repository, quello non sembra sostenere eventuali ganci (essa non ha alcuna configurazione). Questo può, tuttavia, essere aggirato usando un hgwebdir come descritto sopra e con un certo Apache RewriteRule cartina tutto nella sottodirectory desiderata. Questo funziona per me:

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

Buon divertimento con i vostri ganci remoti su HTTP: D

Answer 3

Prima di tutto, voglio correggere un paio di osservazioni di cui sopra.

• ganci sono invocato anche quando si spinge oltre il file system.
• Non è necessario per mantenere il gancio nel repository in cui si desidera loro di operare. Si può anche scrivere lo stesso gancio come nella tua domanda sulla fine dell'utente. Devi cambiare l'evento da changegroup a uscita e anche per specificare l'URL di pronti contro termine a distanza con lo switch -R. Quindi se l'utente ha spinta privilegi sufficienti sul repo remoto, il gancio viene eseguito con successo.

.hg / hgrc

[hooks]
outgoing = hg update -R $HG_URL

Ora verso il vostro problema .... Suggerisco di creare entrambi i ganci prechangegroup e changegroup e la stampa di un output di debug.

.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`"

E anche spingere con l'opzione -v, in modo che si può sapere che il gancio è in esecuzione. Se ancora non riesce a capire, inviare l'output. Potrei essere in grado di aiutare.

Answer 4

Il mio problema era che la mia applicazione hgwebdir corse come l'utente "hg", ma il repository è stato di proprietà di me, così ho dovuto aggiungere in questo po 'di configurazione per hgweb.config per farlo funzionare ganci:

[trusted]
users = me

Answer 5

È necessario avere nel a distanza hgrc di repositiory. Sembra come se è nel vostro repo locale.

Modifica: Dipende anche da come si sta spingendo. Alcuni metodi non invocano ganci sul lato destro. (SSH lo fa, credo HTTP fa, il file system non )

Edit2: Che cosa succede se si preme "localmente" sulla stazione di pronti contro termine a distanza. Si potrebbe avere diversi utenti / permessi tra il server web e il file hgrc. (Vedi [server] e le direttive di fiducia per hgrc.)

Answer 6

Ho avuto lo stesso problema spingendo da Eclipse Windows tramite http, ma dopo aver catturato stderr, ho scoperto che il percorso completo era necessario per il file hg.bat. La mia sezione ganci ora assomiglia a:

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

Spero che questo aiuti qualcun altro.   SteveT

Answer 7

accendere il debugging gancio vedere il motivo per cui non è in esecuzione.

Probabilmente un problema di autorizzazioni o qualcosa del genere.

Answer 8

ha preso un po ', ma ho capito di lavoro.

Ho iniziato con

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

il> & 2 trasporta fino standard error in modo console remote mostreranno esso.

quando a distanza questo dovrebbe output in console se è in esecuzione

hg push https://host/hg   -v

Non è stato.

Stavo usando hgweb.cgi così ho passato a hgweb.wsgi senza alcuna differenza.

quello che ho scoperto è che alcuni ganci non vengono chiamati a distanza.

quando sono passato a

[hooks]
incoming= set >&2

il tag ganci e si impegnano non sembrano ottenere chiamato, ma in entrata e in changeset vieni chiamato. Non ho confermato gli altri.

Ora che ho capito di lavoro sono passato di nuovo a hgweb.cgi e tutto funziona lo stesso.

Answer 9

Lla motivo che ho trovato per questo non ha nulla a che fare con il reindirizzamento stdout a stderr. Come si può vedere nella pagina wiki non è specificato sulla versione corrente 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

Il problema che ho trovato è di circa permessi .

Nella mia configurazione originale, ho avuto un utente, consente di dire hguser con un pronti contro termine sulla sua casa, e uno script per lanciare /etc/init.d/hg.init hg serve. Il problema di essere root è stato gestito da chown, mentre la maggior parte dei file sotto il repo riguardato chown -R hguser:hguser /home/hguser/repo (alcuni dei quali passati a su hguser -c "hg serve ..." ad un certo punto, ma non mente, dal momento che correggerò loro con changegroup = hg update -C)

Soluzione:

• [hooks] (per correggere tutti i file, torna a HGUSER)
• lancio repo/.hg/hgrc (nel mio caso da push)
• hg update -C -r staging sotto tip in development come al solito

Ora dovrebbe funzionare su hg.init

PS: nel mio caso, io invece l'aggiornamento alla testa di un ramo specifico, per cui uso su hguser, per fare l'aggiornamento del server di sosta solo al capo del ramo previsto, anche se il <=> da un altro ramo (come ad esempio <=>)

A proposito il mio <=> sceneggiatura è conclusa in questo modo: (notare il <=> 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

PS: a causa del credito a http : //jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html