Перехватчик Mercurial не работает должным образом

Я провел некоторое время, исследуя это сам. Я думаю, что ответ на проблему описан кратко здесь:

Вывод должен быть перенаправлен на stderr (или /dev/null), потому что stdout используется для потока данных.

По сути, вы не перенаправляете на стандартный вывод и, следовательно, не загрязняете стандартный вывод.

Что ж, пройдя те же этапы разочарования, что и Марк В. некоторое время назад, я, наконец, нашел решение проблемы, по крайней мере, когда удаленное обслуживание выполняется с помощью WSGI-скрипта hgwebdir.

Я обнаружил, что при использовании такого рода удаленной отправки через HTTP или HTTPS Mercurial просто игнорирует все, что вы записываете в файл .hg/hgrc или в свой репозиторий. Однако ввод хука в конфигурацию hgwebdir делает свое дело.

Так что, если нижняя строка вашего скрипта hgwebdir.wsgi выглядит примерно так:

application = hgwebdir('hgweb.config')

раздел конфигурации [hooks] должен войти в упомянутый hgweb.config.

Одним из недостатков является то, что эти хуки выполняются для каждого репозитория, указанного в разделе [paths] этой конфигурации. Несмотря на то, что HG предлагает другую функцию с поддержкой WSGI (hgweb вместо hgwebdir) для обслуживания только одного репозитория, похоже, что он не поддерживает никаких ловушек (и не имеет никакой конфигурации). Однако это можно обойти, используя hgwebdir, как описано выше, и используя некоторые Apache RewriteRule, отображающие все в нужный подкаталог. Этот работает для меня:

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

Получайте удовольствие, используя удаленные перехватчики через HTTP: D

Прежде всего, я хочу исправить несколько комментариев выше.

• Хуки вызываются также при проталкивании через файловую систему.
• Нет необходимости хранить хук в репо, на котором вы хотите, чтобы они работали. Вы также можете написать тот же хук, что и в вашем вопросе, на стороне пользователя. Вы должны изменить событие с группы изменений на исходящие, а также указать URL-адрес удаленного репо с ключом -R. Затем, если отправляющий пользователь имеет достаточные привилегии в удаленном репо, хук будет выполнен успешно.

.hg/hgrc

[hooks]
outgoing = hg update -R $HG_URL

Теперь о вашей проблеме... Я предлагаю создать перехватчики как prechangegroup, так и changegroup и напечатать отладочный вывод.

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

А также нажмите с помощью переключателя -v, чтобы вы могли знать, какой хук запущен. Если вы все еще не можете понять, опубликуйте вывод. Я мог бы помочь.

Моя проблема заключалась в том, что мое приложение hgwebdir работало как пользователь «hg», но репозиторий принадлежал мне, поэтому мне пришлось добавить этот бит конфигурации в hgweb.config, чтобы заставить его запускать хуки:

[trusted]
users = me

Он должен находиться в удаленном репозитории hgrc. Звучит так, как будто это в вашем локальном репо.

Изменить: это также зависит от того, как вы нажимаете. Некоторые методы не вызывают хуки с правой стороны. (подходит ssh, я думаю, что HTTP, а файловая система нет)

Edit2: Что, если вы нажмете «локально» на компьютере удаленного репо. У вас могут быть разные пользователи/разрешения между веб-сервером и файлом hgrc. (См. [сервер] и доверенные директивы для hgrc.)

У меня была такая же проблема с отправкой из Windows Eclipse через http, но после захвата stderr я обнаружил, что нужен полный путь к файлу hg.bat. Мой раздел хуков теперь выглядит так:

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

Надеюсь, это поможет кому-то другому. СтивТ

Попробуйте включить отладку ловушек, чтобы посмотреть, почему он не работает.

Вероятно, проблема с правами доступа или что-то в этом роде.

заняло некоторое время, но я получил его работу.

я начал с

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

>&2 направляет его в стандартную ошибку, чтобы удаленные консоли отображали его.

при удалении это должно выводиться в консоль, если оно запущено

hg push https://host/hg   -v

Это не так.

Я использовал hgweb.cgi, поэтому без разницы переключился на hgweb.wsgi.

я обнаружил, что некоторые хуки не вызываются на удаленном компьютере.

когда я переключил его на

[hooks]
incoming= set >&2

тег хуков и фиксация, похоже, не вызываются, но вызываются входящие и набор изменений. Я не подтверждал других.

теперь, когда я заработал, я вернулся к hgweb.cgi, и все работает так же.

Причина, которую я нашел для этого, не имеет ничего общего с перенаправлением stdout на stderr. Как вы можете видеть на вики-странице, это не указано в текущей версии вики 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

Проблема, которую я обнаружил, связана с разрешениями.

В моей первоначальной настройке у меня был пользователь, скажем, hguser с репозиторием на своем доме, и скрипт /etc/init.d/hg.init для запуска hg serve. Проблема заключалась в том, что hg serve запускался root, в то время как большинство файлов в репозитории относились к hguser (некоторые из них в какой-то момент переключились на root, но это не будет возражать, так как я исправлю их с помощью chown)

Решение:

• chown -R hguser:hguser /home/hguser/repo (чтобы исправить ВСЕ файлы, вернуться к hguser)
• запускаем su hguser -c "hg serve ..." (в моем случае с /etc/init.d/hg.init)
• changegroup = hg update -C моложе [hooks] в repo/.hg/hgrc как обычно

Теперь он должен работать на push

PS: в моем случае я предпочитаю обновляться до главы определенной ветки, поэтому я использую hg update -C -r staging, чтобы промежуточный сервер обновлялся только до главы предполагаемой ветки, даже если tip из другой ветки (например, development )

Кстати, мой сценарий hg.init закончился так: (обратите внимание на часть 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: должно быть указано на http://jf.blogs.teximus.com/2011/01/running-mercurial-hg-serve-on-linux.html