Глава 10. Обработка событий в репозитории с помощью ловушек

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

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

10.1. Обзор ловушек Mercurial

Это краткий список ловушек, поддерживаемых Mercurial. Мы подробно опишем каждую из ловушек позднее, в разделе Раздел 10.7, «Информация для разработчиков ловушек».

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

•changegroup: Выполняется после группы ревизий, внесённых в хранилище извне.

•commit: Выполняется после создания новой ревизии в локальном хранилище.

•incoming: Однократно выполняется для каждого нового набора ревизии, внесённой в репозиторий извне. Примечание: отличается от changegroup тем, что выполняется однократно перед внесением группы ревизий.

•outgoing: Выполняется после передачи группы ревизий из этого репозитория.

•prechangegroup: Выполняемся перед началом приёма группы ревизии в репозиторий.

•precommit: Управляющая. Выполняется перед началом фиксации.

•preoutgoing: Управляющая. Выполняется перед началом передачи группы ревизий из этого репозитория.

•pretag: Управляющая. Выполняется перед созданием tag'а.

•pretxnchangegroup: Управляющая. Выполняется после группы ревизий, принятых в локальный репозиторий из других, но до окончательной обработки транзакции в репозитории, которая сделает изменения постоянными.

•pretxncommit: Управляющая. Выполняется после создания нового набора изменений в локальном хранилище, но перед их фиксацией.

•preupdate: Управляющая. Выполняется перед началом обновления или слияния рабочей директории.

•tag: Выполняется после создания tag'а.

•update: Выполняется после завершения обновления или слияния рабочей директории.

10.2. Ловушки и безопасность

10.2.1. Ловушки выполняются с Вашими привелегиями

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

110

Обработка событий в репозитории с помощью ловушек

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

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

Примечание

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

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

10.2.2. Ловушки не распространяются

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

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

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

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

10.2.3. Возможно переопределение ловушек

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

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

10.2.4. Обеспечение выполнения критических ловушек

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

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

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

111