Mercurial gancho não executar corretamente

Question

Esta deve ser uma coisa muito simples de se executar, mas por algum motivo ele não funcionará com meu repositório Mercurial. Tudo que eu quero é para o repo remoto para hg update executado automaticamente sempre que alguém empurra para ele. Então, eu tenho isso no meu .hg / arquivo hgrc:

[hook]
changegroup = hg update

Simples, certo? Mas por alguma razão, isso nunca é executado. Eu também tentei escrever um shell script que fez isso. .hg / hgrc ficou assim:

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

e hg-update ficou assim:

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

Mas, novamente, isso não atualizar. O conteúdo do hg help são escritos para works.txt, mas nada é escrito para fora para hg update. Existe algo óbvio que estou em falta aqui? Isto tem sido assola-me por dias e eu simplesmente não consigo fazê-lo funcionar.

Atualizar

A aprovação assim que mais uma vez, usando o interruptor -v na linha de comando da minha estação de trabalho empurrando para o repo remoto não imprimir qualquer detalhado mensagens mesmo quando tenho essas linhas echo em .hg/hgrc. No entanto, quando eu faço um empurrão de um clone do repo no mesmo sistema de arquivos (estou logado via SSH), isto é o que eu recebo:

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

Assim, ele funciona, mas novamente só quando eu empurrar a partir do mesmo sistema de arquivos. Ele não funciona se eu tentar empurrar para o repo de outra estação de trabalho através da rede.

Answer 1

Eu passei algum tempo pesquisando isso mesmo. Acho que a resposta para o problema é descrito de forma concisa aqui :

saída tem que ser redirecionado para stderr (ou / dev / null), porque stdout é usado para o fluxo de dados.

Basicamente, você não está redirecionando para stderr, e, portanto, poluindo stdout.

Answer 2

Bem, depois de passar pelas mesmas etapas de frustração como Marc W fez um tempo atrás, eu finalmente encontrei a solução para o problema, pelo menos quando porção remoto é feito com o script hgwebdir WSGI.

Eu descobri que quando se utiliza este tipo de envio remoto via HTTP ou HTTPS, Mercurial simplesmente ignora tudo que você escreve para o arquivo .hg / hgrc ou seu repositório. No entanto, inserindo o gancho na hgwebdir configuração faz o truque.

Então, se a linha de fundo em sua hgwebdir.wsgi script é algo como

application = hgwebdir('hgweb.config')

o [ganchos] config seção precisa de ir para o mencionado hgweb.config .

Uma desvantagem é que estes ganchos são executados para a secção cada repositório listados nos caminhos [] de que a configuração. Mesmo que HG oferece outra função WSGI-capable (hgweb vez de hgwebdir) para servir apenas um único repositório, que não se parecem apoiar qualquer ganchos (nem tem qualquer config). Isto pode, no entanto, ser evitado usando uma hgwebdir como descrito acima e tendo alguns mapa tudo Apache RewriteRule no subdirectório desejado. Este funciona para mim:

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

Divirta-se com seus ganchos remotos através de HTTP: D

Answer 3

Primeiro de tudo, eu quero corrigir alguns comentários acima.

• Hooks são invocados também ao empurrar ao longo do sistema de arquivos.
• Não é necessário para manter o gancho no repo em que você quer que eles operam. Você também pode escrever o mesmo gancho como na sua pergunta sobre o usuário final. Você tem que mudar o evento de changegroup a saída e também para especificar a URL de repo remoto com a opção -R. Em seguida, se o usuário empurrando tem privilégios suficientes no repo remoto, o gancho vai executar com sucesso.

.hg / hgrc

[hooks]
outgoing = hg update -R $HG_URL

Agora, para o seu problema .... Eu sugiro a criação de ambos os ganchos prechangegroup e changegroup e imprimir alguma saída de depuração.

.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 também empurrar com a opção -v, de modo que você pode saber qual gancho está em execução. Se você ainda não consegue descobrir, postar a saída. Eu poderia ser capaz de ajudar.

Answer 4

Meu problema era que minha correu aplicação hgwebdir como o usuário "hg", mas o repositório foi possuído por mim, então eu tive que adicionar neste pouco de configuração para hgweb.config para obtê-lo para executar os ganchos:

[trusted]
users = me

Answer 5

Você precisa tê-lo no remoto hgrc de repositiory. Soa como se ele está em sua repo local.

Edit: Também depende de como você está empurrando. Alguns métodos não invocar ganchos no lado direito. (Ssh faz, eu acho HTTP faz, sistema de arquivos não )

Edit2: O que se você empurrar "localmente" no computador do repo remoto. Você pode ter diferentes usuários / permissões entre o servidor eo arquivo hgrc. (Ver [servidor] e directivas confiáveis ??para hgrc.)

Answer 6

Eu tive o mesmo problema empurrando a partir do Windows Eclipse via http, mas depois de capturar stderr, descobri que o caminho completo era necessária para o arquivo hg.bat. minha seção ganchos agora se parece com:

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

Espero que isso ajude alguém. SteveT

Answer 7

Tente ligar gancho depuração para ver por que ele não está funcionando.

provável um permissões emitir ou algo parecido.

Answer 8

Demorou um pouco, mas eu tenho que trabalhar.

Eu comecei com

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

os> & 2 tubos de TI para erro padrão de modo consoles remotos irá mostrá-lo.

quando remoto isso deve saída no console se ele está sendo executado

hg push https://host/hg   -v

Não foi.

Eu estava usando hgweb.cgi então eu troquei para hgweb.wsgi sem diferença.

O que eu descobri é que alguns ganchos não são chamados no controle remoto.

quando eu mudei-o para

[hooks]
incoming= set >&2

tag ganchos e comprometer não parecem ter chamado, mas de entrada e de alterações não obter chamado. Eu não confirmaram os outros.

Agora que eu tenho que trabalhar Eu mudei para hgweb.cgi e tudo funciona da mesma.

Answer 9

A reconstrução da razão que eu encontrei para isso não tem nada a ver com o redirecionamento stdout para stderr. Como você pode ver na página wiki não é especificado na versão atual do 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

O problema que eu encontrei é em torno de permissões .

Na minha configuração original, eu tinha um usuário, digamos hguser com um repo em sua casa, e uma /etc/init.d/hg.init script para hg serve lançamento. O hg serve problema é estava sendo dirigido por root, enquanto a maioria dos arquivos sob o repo pertencia a hguser (alguns deles passaram a root em algum momento, mas não vai se importar, desde que eu vou corrigi-los com chown)

Solução:

• chown -R hguser:hguser /home/hguser/repo (para todos os arquivos corretos, de volta à hguser)
• su hguser -c "hg serve ..." lançamento (no meu caso de /etc/init.d/hg.init)
• changegroup = hg update -C sob [hooks] em repo/.hg/hgrc como de costume

Agora, ele deve funcionar em push

PS: no meu caso, prefiro atualizar para a cabeça de um ramo específico, então eu uso hg update -C -r staging, para fazer a atualização servidor de teste apenas ao chefe do ramo pretendido, mesmo se o tip é de outro ramo (como development por exemplo)

BTW meu script hg.init acabou assim: (aviso a parte su hguser)

#!/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: devido crédito para http : //jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html