При запуске Вами команд Mercurial в хранилище и команд, вызывающих выполнение ловушек, эти ловушки выполняются на Вашей системе, в Вашем аккаунте и с Вашим уровнем доступа. Ловушки частично состоят из исполняемого кода, так что относитесь к ним с достаточным подозрением. Не устанавливайте ловушку, если не знаете Кто и Зачем её написал и Что она делает.

В некоторых случаях Вы можете столкнуться с ловушками, которые Вы не устанавливали себе. Если вы работаете на незнакомой системе, Mercurial может выполнять ловушки, определённые в системном глобальном ~/.hgrc файле.

Если вы работаете с репозиторием, принадлежащем другому пользователю, Mercurial может запускать ловушки, определённые в пользовательском репозитории, но он будет работать от «Вас». Например, если Вы выполняете hg pull из этого репозитория, а его .hg/hgrc определяет локальные outgoing ловушки, то ловушка будет работать под вашей учетной записью пользователя, даже если вы не владелец репозитория.

	Примечание
	Это применимо только если Вы забираете изменения из репозитория в локальной или сетевой файловой системе. Если Вы забираете изменения по http или ssh, то любая outgoing ловушка будет запущена под аккаунтом, из-под которого выполняется серверный процесс, на сервере.

Для просмотра ловушек, определённых в репозитории, используйте команду hg showconfig hooks. Если Вы работаете в одном репозитории, но общаетесь с другим, которыми не владеете (например, используете hg pull или hg incoming), запомните что это ловушки другого хранилища, не Ваши, и Вы должны их проверять.

В Mercurial ловушки не попадают под контроль ревизий и не распространяются, когда Вы клонируете репозиторий, или забираете изменения из репозитория. Причина этого проста: ловушка это произвольный кусок исполняевого кода. Она работает от Вашей учётной записи, с Вашим уровнем привелегий, на Вашей машине.

В любой распределенной системе контроля версий было бы крайне безрассудно реализовывать версионноконтролируемые ловушки, так как это даёт легкий способ компроментации аккаунтов пользователей системы управления версиями.

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

В корпоративной интрасети это несколько легче контролировать, так как Вы можете, например, создать «стандартную» установку Mercurial на файловой системе NFS и использовать общесистемный ~/.hgrc файл для определения ловушек для всех пользователей. Тем не менее, здесь тоже есть ограничения; см. ниже.

Mercurial позволяет изменить ловушку, переопределив её. Вы можете отключить ловушку, установив значение равным пустой строке, или по своему желанию изменить её поведение.

Вы должны понимать при распространении общесистемного или общесайтового ~/.hgrc файла, определяющего какие-либо ловушки, что пользователи могут отключать или переопределять эти ловушки.

Иногда Вам может понадобится соблюдение политики, и Вы не хотите, чтобы другие могли её обойти. Например, требование, что каждое изменение должно проходить строгий набор тестов. Определение этого требования с помощью ловушки в общесайтовом ~/.hgrc не будет работать для удаленных пользователей с ноутбуками, и, конечно, локальные пользователи также могут её обойти, переопределив ловушку.

Вместо этого, Вы можете настроить политику использования Mercurial так, чтобы люди распространяли изменения через хорошо известный «канонический» сервер, который защищён и должным образом настроен.

Один из способов осуществления этого — сочетание социальной инженерии и технологии. Настройте ограниченный доступ к учетной записи: пользователи могут отправлять изменения по сети в репозиторий этой учетной записи, но не могут входить в аккаунт и запускать команды оболочки. В этом случае пользователи смогут отправлять изменения, содержащие любое любимое ими старьё.

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

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

$ echo 'commit.when = echo -n "date of commit: "; date' >> .hg/hgrc
$ echo a >> a
$ hg commit -m 'i have two hooks'
committed 95279e34c052b63a7ffa8778ae428644dd2071a6
date of commit: Thu Feb  2 14:09:53 GMT 2012

Mercurial позволяет сделать это путем добавления расширения к концу имени ловушки. Вы расширяете имя ловушки, добавляя к названию ловушки (после «.») произвольный текст. Например, Mercurial будет работать как с commit.foo, так и с commit.bar при событии фиксации (commit).

Чтобы задать четкий порядок выполнения, когда есть несколько ловушек, определенных для события, Mercurial сортирует ловушки в по расширению, и выполняет команды ловушки в этом порядке сортировки. В приведенном выше примере, он будет выполнять в следующем порядке commit, commit.bar, commit.foo.

Это хорошая идея использовать несколько описательных расширений при определении новых ловушек. Это поможет вам вспомнить для чего эта ловушка. Если ловушка не выполнилась, вы получите сообщение об ошибке, которое содержит имя и расширение ловушки, поэтому использование описательных расширений могло бы сразу дать вам намек на то, почему не сработала ловушка (смотрите раздел Раздел 10.3.2, «Управление возможностью выполнения действия» для примера).

В наших предыдущих примерах мы использовали ловушку commit, которая запускается после завершения фиксации. Это одна из нескольких ловушек Mercurial, которые выполняются после того, как действие произошло. Такие ловушки не имеют возможности влиять на само действие.

Mercurial определяет целый ряд событий, которые происходят до начала действия, или после его начала, но до его завершения. В ловушки, которые срабатывают при этих событиях, добавлена возможность выбора, продолжить ли выполнение этого действия, или прервать.

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

Если ловушка pretxncommit завершает свою работу с кодом возврата 0, транзакция завершается; фиксация заканчивается, и выполняется ловушка commit. Если ловушка pretxncommit выходит с ненулевым кодом возврата, транзакция откатывается; метаданные, представляющие изменения стираются, а ловушка commit не выполняется.

$ cat check_bug_id
#!/bin/sh
# check that a commit comment mentions a numeric bug id
hg log -r $1 --template {desc} | grep -q "\<bug *[0-9]"
$ echo 'pretxncommit.bug_id_required = ./check_bug_id $HG_NODE' >> .hg/hgrc
$ echo a >> a
$ hg commit -m 'i am not mentioning a bug id'
transaction abort!
rollback completed
abort: pretxncommit.bug_id_required hook exited with status 1
$ hg commit -m 'i refer you to bug 666'
committed 13b236affeff106b31ae144e61b115cc36f3a63e
date of commit: Thu Feb  2 14:09:54 GMT 2012

Ловушка в приведенном выше примере проверяет, что комментарий при фиксации содержит id бага. Если он есть, фиксация завершается. Если нет, то происходит откат.

Вы можете написать ловушку как обычную программу, обычно скрипт на языке shell, или, как функции Python, которая выполняется в рамках процесса Mercurial.

Написание ловушки, как внешней программы имеет то преимущество, что не требует знаний о внутреннем строении Mercurial. Вы можете вызвать нормальную команду Mercurial для получения любой дополнительной информации. Недостаток в том, что внешние ловушки медленнее, чем ловушки внутри процесса.

Ловушка в процессе выполнения Python имеет полный доступ к Mercurial API, и не «создаёт» другой процесс, так что по своей сути быстрее, чем внешняя ловушка. Кроме того, легче получить больше информации, которая требуется ловушке с помощью API, чем выполнив команды Mercurial.

Если вы знакомы с Python, или требуются ловушки с высокой производительностью, использование ловушек в Python может быть хорошим выбором. Однако, если у вас есть простая ловушка и не нужно заботиться о производительности (вероятно, большинство ловушек), скрипт, это прекрасно.

Mercurial вызывает каждую ловушку с набором четких параметров. В python, параметр передается в качестве аргументов функции ловушки. Для внешней программы, параметры передаются как переменные среды.

Написана ли ваша ловушка в python или скриптом, конкретные имена и значения параметров будут одинаковы. Логический параметр будет представлен как логическое значение в python, и как число 1 (для «true») или 0 (для «false»), в случае переменных среды для внешних ловушек. Если параметр ловушки называется foo, имя аргумента ловушки в python будет также называться foo, в то время как переменная среды для внешних ловушек будет называться HG_FOO.

Успешно выполнившаяся ловушка, должна выйти с кодом возврата 0, если она внешняя, или вернуть логическое «false», если внутрипроцессная. Отказ обозначается ненулевым кодом возврата из внешних ловушки, или внутри процесса ловушка возвращает логическое «true». Если в процессе выполнения ловушка генерирует исключение, ловушка считается выполнившейся неудачно.

Для контролирующей действие ловушки 0/false означает «разрешить», не-ноль/true/исключение означает «запретить».

При определении внешней ловушки в вашем ~/.hgrc и ловушка запускаются, её переменные передаются вашей оболочке, которая интерпретирует её. Это означает, что вы можете использовать обычные конструкции shell в теле ловушки.

Исполняемая ловушка всегда выполняется с текущей директорией установленой в корневую директорию репозитория.

Каждый параметр ловушки передается в качестве переменной окружения, имя в верхнем регистре с префиксом «HG_».

За исключением параметров ловушек, Mercurial не устанавливает и не изменяет переменные окружения при запуске ловушки. Это полезно помнить, если вы пишете ловушку на веб-сервере, который может быть запущен под целым рядом различных пользователей с различными наборами переменных окружения. В многопользовательской среде, вы не должны полагаться на переменные окружения, которые установлены в значения вашей среды, при тестировании ловушки.

Cинтаксис ~/.hgrc для определения в внутренних ловушек несколько иной, чем для внешних ловушек. Значение ловушки должно начинаться с текста «python:», и продолжаться полностью определённым именем вызываемого объекта для использования в качестве значения ловушки.

Модуль, в котором находится ловушка автоматически импортируются при выполнении ловушки. До тех пор пока у вас есть имя модуля и правильный PYTHONPATH, это должно «просто работать».

Следующий ~/.hgrc фрагмент иллюстрирует синтаксис и смысл понятий, которые мы только что описали.

[hooks]
commit.example = python:mymodule.submodule.myhook

Когда Mercurial запускает ловушку commit.example, он импортирует mymodule.submodule, ищет объект с именем myhook, и вызывает его.

Простейших внутрипроцессный хук ничего не делает, но иллюстрирует основную формат api хуков:

def myhook(ui, repo, **kwargs):
    pass

Первый аргумент ловушки в python всегда ui объекта. Второй представляет собой репозиторий объектов, используемый в данный момент, это всегда localrepository. После этих двух аргументов идут другие аргументы. Какие аргументы будут переданы зависит от ловушки, но ловушка может игнорировать аргументы она не заботится о помещении их в аргументы словари такие как **kwargs выше.

Трудно представить себе полезное сообщение при фиксации слишком коротким. Простая ловушка pretxncommit в приведенном ниже примере поможет предотвратить фиксацию ревизии с сообщением, которое составляет менее 10 байт.

$ cat .hg/hgrc
[hooks]
pretxncommit.msglen = test `hg tip --template {desc} | wc -c` -ge 10
$ echo a > a
$ hg add a
$ hg commit -A -m 'too short'
transaction abort!
rollback completed
abort: pretxncommit.msglen hook exited with status 1
$ hg commit -A -m 'long enough'

Интересным эффект при использовании связанных с commit ловушек, чтобы помочь вам писать чистый код. Простой пример «чистого кода» является утверждение о том, что изменения не должны добавлять новые строки текста, которые содержат «конечные пробелы». Конечные пробелы это ряд пробелов и табуляций в конце строки текста. В большинстве случаев, конечные пробелы не нужны, представляют невидимый шум, но это иногда это проблема, и люди часто предпочитают, избавляться от них.

Вы можете использовать precommit или pretxncommit ловушку для проверки конечных пробелов. Если вы используете ловушку precommit, ловушка не будет знать, какие файлы вы фиксируете, так что придется проверять каждый измененный файл в репозитории на завершающие пробелы. Если вы хотите зафиксировать изменения в файле foo, но файл bar содержит конечные пробелы, проверка в ловушке precommit может предотвратить фиксацию foo из-за проблемы с bar. Это кажется не правильным.

Если вы выберите ловушку pretxncommit, проверка выполнится незадолго до завершения транзакции. Это позволит вам проверить проблемы только в тех файлах, которые фиксируются. Однако, если вы ввели сообщение при фиксации в интерактивном режиме и ловушка не выполнилась, то транзакция будет отозвана, вы должны будете заново ввести сообщение после того как исправите конечные пробелы и запустить hg commit еще раз.

$ cat .hg/hgrc
[hooks]
pretxncommit.whitespace = hg export tip | (! egrep -q '^\+.*[ \t]$')
$ echo 'a ' > a
$ hg commit -A -m 'test with trailing whitespace'
adding a
transaction abort!
rollback completed
abort: pretxncommit.whitespace hook exited with status 1
$ echo 'a' > a
$ hg commit -A -m 'drop trailing whitespace and try again'

В вышеприведенном примере мы используем ловушку pretxncommit, которая проверяет текст на лишние пробелы в конце строк. Несмотря на простой и короткий код ловушка не очень полезная, так как всего лишь прерывает выполнение со статусом ошибки при попытке добавления строки из файла с лишними пробелами — но при этом не говорит ничего о том, где именно можно найти ошибку. У ловушки есть еще одна особенность — она проверяет на лишние пробелы только изменённые в файле строки, полностью игнорируя неизменённые.

#!/usr/bin/env python
#
# save as .hg/check_whitespace.py and make executable

import re

def trailing_whitespace(difflines):
    # 
    linenum, header = 0, False

    for line in difflines:
        if header:
            # remember the name of the file that this diff affects
            m = re.match(r'(?:---|\+\+\+) ([^\t]+)', line)
            if m and m.group(1) != '/dev/null':
                filename = m.group(1).split('/', 1)[-1]
            if line.startswith('+++ '):
                header = False
            continue
        if line.startswith('diff '):
            header = True
            continue
        # hunk header - save the line number
        m = re.match(r'@@ -\d+,\d+ \+(\d+),', line)
        if m:
            linenum = int(m.group(1))
            continue
        # hunk body - check for an added line with trailing whitespace
        m = re.match(r'\+.*\s$', line)
        if m:
            yield filename, linenum
        if line and line[0] in ' +':
            linenum += 1

if __name__ == '__main__':
    import os, sys
    
    added = 0
    for filename, linenum in trailing_whitespace(os.popen('hg export tip')):
        print >> sys.stderr, ('%s, line %d: trailing whitespace added' %
                              (filename, linenum))
        added += 1
    if added:
        # save the commit message so we don't need to retype it
        os.system('hg tip --template "{desc}" > .hg/commit.save')
        print >> sys.stderr, 'commit message saved to .hg/commit.save'
        sys.exit(1)

Выше версия гораздо более сложная, но и более полезная. Она анализирует унифицированный формат, чтобы увидеть, если добавились строки с конечными пробелами она печатает имя файла и номер строки, для каждого такого происшествия. Еще лучше, если изменение добавляет конечные пробелы, это ловушка сохраняет комментарии и печатает имя сохраненного файла перед выходом и говорит mercurial, откатить транзакцию, так что вы можете использовать опцию -l filename команды hg commit для повторного использования сохраненного сообщения фиксации, как только вы исправите проблемы.

$ cat .hg/hgrc
[hooks]
pretxncommit.whitespace = .hg/check_whitespace.py
$ echo 'a ' >> a
$ hg commit -A -m 'add new line with trailing whitespace'
a, line 2: trailing whitespace added
commit message saved to .hg/commit.save
transaction abort!
rollback completed
abort: pretxncommit.whitespace hook exited with status 1
$ sed -i 's, *$,,' a
$ hg commit -A -m 'trimmed trailing whitespace'
a, line 2: trailing whitespace added
commit message saved to .hg/commit.save
transaction abort!
rollback completed
abort: pretxncommit.whitespace hook exited with status 1

В качестве последнего отступления, к сведению в приведенном выше примере используется особенность редактора sed — редактирование на месте, чтобы избавиться от конечных пробелов в файле. Это краткое и достаточно полезное действие, и я буду ещё повторять его здесь (Использование perl тоже неплохая мера).

perl -pi -e 's,\s+$,,' filename

Расширение acl позволяет вам контролировать, какие удаленные пользователи могут отправлять ревизии в сетевой сервер. Вы можете защитить любую часть репозитория (включая весь репозиторий), так что конкретные удаленные пользователи могут отправлять ревизии, которые не влияют на охраняемую часть.

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

[hooks]
pretxnchangegroup.acl = python:hgext.acl.hook

[acl.allow]
docs/** = docwriter
[acl.deny]
source/sensitive/** = intern

[ui]
debug = true

Расширение bugzilla добавляет комментарии к ошибке Bugzilla, когда находит ссылку на id бага в комментарии фиксации. Вы можете установить эту ловушку на общем сервере, так что каждый раз, удаленный пользователь передавая изменения на этот сервер, будет запускать ловушку.

Расширение добавляет комментарий к ошибке, которая выглядит следующим образом (вы можете настроить содержание комментария — смотрите ниже):

Changeset aad8b264143a, made by Joe User
	<joe.user@domain.com> in the frobnitz repository, refers
	to this bug. For complete details, see
	http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a
	Changeset description: Fix bug 10483 by guarding against some
	NULL pointers

Значение этой ловушки в том, что она автоматизирует процесс обновления ошибка в любое время когда создаётся ревизия относящаяся к нему. Если вы настроите ловушку должным образом, людям будет легко просмотреть ревизию, которая ссылается на данный баг, прямо из комментариев bugzilla.

Вы можете использовать код в этой книге в качестве отправной точки для некоторых более экзотических рецептов интеграции с Bugzilla. Вот несколько возможностей:

[hooks]
incoming.bugzilla = python:hgext.bugzilla.hook

[usermap]
jane.user@example.com = jane

# regular hgrc file refers to external usermap file
[bugzilla]
usermap = /home/hg/repos/userdata/bugzilla-usermap.conf

# bugzilla-usermap.conf - inside a hg repository
[usermap] stephanie@example.com = steph

[web]
baseurl = http://hg.domain.com/

[bugzilla]
host = bugzilla.example.com
password = mypassword version = 2.16
# server-side repos live in /home/hg/repos, so strip 4 leading
# separators
strip = 4
hgweb = http://hg.example.com/
usermap = /home/hg/repos/notify/bugzilla.conf
template = Changeset {node|short}, made by {author} in the {webroot}
  repo, refers to this bug.\n
  For complete details, see
  {hgweb}{webroot}?cmd=changeset;node={node|short}\n
  Changeset description:\n
  \t{desc|tabindent}

hg_user = (httpd_user)
NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s

#!/bin/sh
cd `dirname $0` && ./processmail "$1" nobody@example.com

cannot find bugzilla user id for john.q.public@example.com

Хотя встроенный веб-сервер Mercurial предоставляет rss каналы изменений в каждом репозитории, многие люди предпочитают получать уведомления об изменениях по электронной почте. Ловушка notify позволяет посылать уведомления множеству адресов электронной почты, когда поступают ревизии, в которых заинтересованы абоненты.

Как и в ловушке bugzilla, ловушка notify управляется с помощью шаблонов, поэтому вы можете настроить содержание уведомлений, которые она посылает.

По умолчанию, ловушка notify включает в себя diff каждой ревизии, которые он посылает. Вы можете ограничить размер diff или отключить эту функцию полностью. Это полезно, позволяя абонентам просматривать изменения немедленно, а не нажатием ссылки в письме.

[hooks]
# send one email per group of changes
changegroup.notify = python:hgext.notify.hook
# send one email per change
incoming.notify = python:hgext.notify.hook

[notify]
# really send email
test = false
# subscriber data lives in the notify repo
config = /home/hg/repos/notify/notify.conf
# repos live in /home/hg/repos on server, so strip 4 "/" chars
strip = 4
template = X-Hg-Repo: {webroot}\n
  Subject: {webroot}: {desc|firstline|strip}\n
  From: {author}
  \n\n
  changeset {node|short} in {root}
  \n\ndetails:
  {baseurl}{webroot}?cmd=changeset;node={node|short}
  description: {desc|tabindent|strip}

[web]
baseurl =
http://hg.example.com/

X-Hg-Repo: tests/slave
Subject: tests/slave: Handle error case when slave has no buffers
Date: Wed,  2 Aug 2006 15:25:46 -0700 (PDT)

changeset 3cba9bfe74b5 in /home/hg/repos/tests/slave

details:
http://hg.example.com/tests/slave?cmd=changeset;node=3cba9bfe74b5 

description: Handle error case when slave has no buffers

diffs (54 lines):
diff -r 9d95df7cf2ad -r 3cba9bfe74b5 include/tests.h
--- a/include/tests.h      Wed Aug 02 15:19:52 2006 -0700
+++ b/include/tests.h      Wed Aug 02 15:25:26 2006 -0700
@@ -212,6 +212,15 @@ static __inline__
void test_headers(void *h)
[...snip...]

Все внутрипроцеcсные ловушки вызываются с аргументами в следующей форме:

def myhook(ui, repo, **kwargs): pass

Здесь параметр ui это объект ui, параметр repo — объект localrepository. Имена и значения параметров **kwargs зависят от вызываемой ловушки и обладают общими чертами:

Внутрепроцессные ловушки вызываются без смены рабочей директории процесса (в отличие от внешних ловушек, которые запускаются в корне репозитория). Они также не должны менять рабочую директорию процесса, в противном случае любые вызовы Mercurial API потерпят неудачу.

Если ловушка возвращает булевое значение «false», считается что вызов прошел успешно. Если возвращается «true» или генерируется исключение, считается что вызов завершился неудачей. Полезно думать о вызовах ловушек как «скажи мне, если ты потерпел неудачу».

Помните, что ID набора изменений передается в Python как шестнадцатеричная строка, а не как бинарный хеш, который использует API Mercurial. Для конвертации ее в бинарный вид используйте функцию bin.

Внешние ловушки передаются командной оболочке пользователя, запустившего Mercurial. Доступны фичи командной оболочки, как, например, подстановка переменных и команды перенаправления. Ловушка запускается в корневой директории хранилища (в отличие от in-process ловушек, которые работают в той же директории из которой был запущен Mercurial).

Параметры ловушке передаются как переменные среды. Каждое имя переменной преобразуется в верхний регистр с префиксом «HG_». Например, если имя параметра «node», имя переменной среды, представляющее параметр, будет «HG_NODE».

Булевы параметры представляется в виде строки «1» для «истинно», «0» для «ложь». Если переменная окружения называется HG_NODE, HG_PARENT1 или HG_PARENT2, она содержит ID набора изменений в виде шестнадцатеричной строки. Для представления «null changeset ID» используется пустая строка вместо строки нулей. Если переменная окружения называется HG_URL, она будет содержать адрес удалённого хранилища, если его можно определить.

Если ловушка завершается с кодом возврата, равным нулю, то это успешное завершениие. Если она завершилась с ненулевым статусом, то «всё» плохо.

Ловушку, которая срабатывает при перемещении набора изменений между локальным хранилищем и каким-либо другим можно настроить на нахождение информации «о той стороне». Mercurial знает как набор изменений передаётся, и , во многих случаях, куда и откуда они передаются.

Эта ловушка запускается после того как группа уже существующих ревизий добавляется в репозиторий, например, через hg pull или hg unbundle. Эта ловушка выполняется один раз за операцию, добавления одной или более ревизий. В отличие от ловушки incoming, которая выполняется один раз на каждую ревизию, независимо от того, прибыли ли ревизии в группе.

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

Параметры ловушки:

Смотрите также: incoming (раздел Раздел 10.8.3, «incoming — после добавления одной удаленной ревизии»), prechangegroup (раздел Раздел 10.8.5, «prechangegroup — до начала добавления ревизий удалённого репозитория»), pretxnchangegroup (раздел Раздел 10.8.9, «pretxnchangegroup — перед завершением добавления ревизий удалённого репозитория»)

Эта ловушка запускается после того, как создан новая ревизия

Параметры ловушки:

Смотрите также: precommit (раздел Раздел 10.8.6, «precommit — перед фиксацией ревизии»), pretxncommit (раздел Раздел 10.8.10, «pretxncommit — перед завершением фиксации новой ревизии»)

Эта ловушка запускается после добавления в репозиторий ранее существующей ревизии, например, с помощью hg push. Если группа ревизий добавляется одной операцией, то эта ловушка вызывается для каждой добавленной ревизии.

Вы можете использовать эту ловушку для тех же целей что и ловушку changegroup (см. раздел Раздел 10.8.1, «changegroup — после внесения внешних ревизий»); просто иногда более удобно выполнить один раз ловушку для группы ревизий, в то время как в другом случае удобнее выполнять ловушку один раз для ревизии.

Параметры этого хука:

Смотрите также: changegroup (раздел Раздел 10.8.1, «changegroup — после внесения внешних ревизий») prechangegroup (раздел Раздел 10.8.5, «prechangegroup — до начала добавления ревизий удалённого репозитория»), pretxnchangegroup (раздел Раздел 10.8.9, «pretxnchangegroup — перед завершением добавления ревизий удалённого репозитория»)

Эта ловушка запускается после того как группа ревизий будет распространена за пределы этого репозитория, например при использовании команд hg push или hg bundle.

Одно из применений данного хука — это уведомление администраторов что изменения были вытянуты.

Параметры этого хука:

Смотрите также: preoutgoing (раздел Раздел 10.8.7, «preoutgoing — до начала передачи ревизий в другие репозитории»)

Эта контролирующая ловушка запускается до того как Mercurial начнет добавлять группы ревизий из другого репозитория.

Эта ловушка не содержит информации о добавляемой ревизии, потому что она запускается до разрешения передачи этой ревизии. Если эта ловушка возвращает ошибку, ревизия не передаётся.

Эту ловушку можно использовать для запрета внешним пользователям вносить изменения в репозиторий. Например так можно «заморозить» ветку на сервере, на время или постоянно, от пользователей в то время как администратор будет модифицировать репозиторий.

Параметры этого хука:

Смотрите также: changegroup (раздел Раздел 10.8.1, «changegroup — после внесения внешних ревизий»), incoming (раздел Раздел 10.8.3, «incoming — после добавления одной удаленной ревизии»), pretxnchangegroup (раздел Раздел 10.8.9, «pretxnchangegroup — перед завершением добавления ревизий удалённого репозитория»)

Эта ловушка запускается до начала фиксации Mercurial'ом новой ревизии. Выполняется до того, как Mercurial сформирует какие-либо метаданные для передачи, такие как файлы, сообщения, или даты.

Одно из использований этой ловушки — запрет возможности фиксировать новые ревизии, позволяя в то же время входящие ревизии. Другой вариант использования состоит в том, чтобы запустить сборку или тест, и разрешить фиксацию ревизии только в том случае, если сборка или тесты прошли успешно.

Параметры этого хука:

Если фиксация завершится, то родители рабочей директории станут родителями новой ревизии.

Смотрите также: commit (раздел Раздел 10.8.2, «commit—после создания новой ревизии»), pretxncommit (раздел Раздел 10.8.10, «pretxncommit — перед завершением фиксации новой ревизии»)

Этот ловушка вызывается до того как Mercurial узнает идентификатор ревизии, который будет передаваться.

Один из вариантов использования для этой ловушки — предотвращение передачи изменений в другой репозиторий.

Параметры ловушки:

Смотрите также: outgoing (раздел Раздел 10.8.4, «outgoing — после распространения ревизии»)

Этот контролирующая ловушка запускается до создания тега. Если ловушка выполняется успешно, создание тега продолжается. Если ловушка не выполняется удачно, тег не создается.

Параметры ловушки:

Если тег должен быть создан под управлением ревизиями, ловушки precommit и pretxncommit (в разделе Раздел 10.8.2, «commit—после создания новой ревизии» и в разделе Раздел 10.8.10, «pretxncommit — перед завершением фиксации новой ревизии»), также будут запущены.

Смотрите также: tag (раздел Раздел 10.8.12, «tag — после создания метки ревизии»)

Этот контрольная ловушка запускается перед завершением транзакции, которая управляет добавлением группы новых ревизий из другого репозитория. Если ловушка выполняется успешно, транзакция завершается, и все ревизии становятся постоянными в этом репозитории. Если ловушка срывается, транзакция откатывается, а данные ревизий стираются.

Эта ловушка можете получить доступ к метаданным, связанными с почти добавленными ревизиями, но она не должна ничего делать с этими данными. Она также не должна изменять рабочий каталог.

Когда запускается эта ловушка другие процессы Mercurial, имеющие доступ к этому репозиторию, они будут иметь возможность увидеть почти добавленные ревизии, как будто они постоянные. Это может привести к гонкам, если не принять меры,чтобы их избежать.

Эту ловушку можно использовать для автоматической проверки ревизий. Если ловушка не удалось, все ревизии будут «отклонены» и транзакция будет отклонена.

Параметры ловушки:

Смотрите также: changegroup (раздел Раздел 10.8.1, «changegroup — после внесения внешних ревизий»), incoming (раздел Раздел 10.8.3, «incoming — после добавления одной удаленной ревизии»), prechangegroup (раздел Раздел 10.8.5, «prechangegroup — до начала добавления ревизий удалённого репозитория»)

Это управляющий хук запускается перед транзакцией, которая сделает новую фиксацию завершённой. Если хук отработал успешно, транзакция завершается и ревизия принимается в репозиторий. Если хук вернул ошибку — транзакция откатывается и принятые данные удаляются.

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

Пока выполняется этот хук, другие процессы Mercurial, обращающиеся к этому хранилищу, видят временное состояние хранилища как постоянное. Это может привести к ошибкам, если вы не предусмотрели мер предотвращения этого.

Параметры ловушки:

Смотрите также: precommit (раздел Раздел 10.8.6, «precommit — перед фиксацией ревизии»)

Эта управляющая ловушка, запускается перед началом обновления/слияния рабочей директории. Запускается только если внутренняя pre-update проверка Mercurial'а определила, что обновление/слияние возможны. Если ловушка возвращает успешный код возврата, обновление/слияние продолжается; иначе даже не начинается.

Параметры ловушки:

Смотрите также: update (раздел Раздел 10.8.13, «update — после обновления или слияния рабочей директории»)

Ловушка выполняется после создания метки ревизии.

Параметры ловушки:

Если созданная метка попадает под контроль версий, то перед этим вызывается ловушка commit (раздел Раздел 10.8.2, «commit—после создания новой ревизии»)

Смотрите также: pretag (раздел Раздел 10.8.8, «pretag — перед тегированием ревизии»)

Ловушка запускается после завершения обновления или объединения изменений. Поскольку слияние может не сработать (если внешняя команда hgmerge не выполнилась на конфликтных файлах), то эта ловушка сообщит — успешно ли обновление/слияние.

Смотрите также: preupdate (раздел Раздел 10.8.11, «preupdate — перед обновлением или слиянием рабочей директории.»).