view ja/hook.tex @ 835:8a3041e6f3cb

reflect comments by Hiroshi Someya.

%\chapter{Handling repository events with hooks}
\chapter{$B%j%]%8%H%j%$%Y%s%H$r%U%C%/$G<h$j07$&(B}
\label{chap:hook}

%Mercurial offers a powerful mechanism to let you perform automated
%actions in response to events that occur in a repository.  In some
%cases, you can even control Mercurial's response to those events.

Mercurial$B$O!$%j%]%8%H%j$K5/$3$k%$%Y%s%H$KBP$7$F<+F02=$5$l$?%"%/%7%g%s$r9T(B
$B$&6/NO$J%a%+%K%:%`$r;}$C$F$$$k!%$$$/$D$+$N%$%Y%s%H$KBP$7$F$O!$(BMercurial$B$N(B
$BH?1~$r@)8f$9$k$3$H$b$G$-$k!%(B

%The name Mercurial uses for one of these actions is a \emph{hook}.
%Hooks are called ``triggers'' in some revision control systems, but
%the two names refer to the same idea.

Mercurial$B$O(B\emph{$B%U%C%/(B}$B$H8F$P$l$k5!9=$r;H$C$F%"%/%7%g%s$r9T$&!%%U%C%/$O(B
$BB>$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$G$O(B``$B%H%j%,(B''$B$H8F$P$l$k$3$H$b$"$k$,!$(B
$B$3$l$i$O<B:]$OF1$8$b$N$G$"$k!%(B

%\section{An overview of hooks in Mercurial}
\section{Mercurial$B$G$N%U%C%/$N35MW(B}

%Here is a brief list of the hooks that Mercurial supports.  We will
%revisit each of these hooks in more detail later, in
%section~\ref{sec:hook:ref}.

Mercurial$B$,%5%]!<%H$9$k%U%C%/$N0lIt$rNs5s$9$k!%8D!9$N%U%C%/$K$D$$$F$O(B
$B8e$[$I(Bsection~\ref{sec:hook:ref}$B$G>\:Y$K?($l$k!%(B

\begin{itemize}
%\item[\small\hook{changegroup}] This is run after a group of
%  changesets has been brought into the repository from elsewhere.
\item[\small\hook{changegroup}] $B%A%'%s%8%;%C%H%0%k!<%W$,30It$+$i%j%]%8%H(B
	     $B%j$K2C$o$C$?8e$G8F$S=P$5$l$k!%(B

%\item[\small\hook{commit}] This is run after a new changeset has been
%  created in the local repository.
\item[\small\hook{commit}] $B%m!<%+%k%j%]%8%H%j$G?7$7$$%A%'%s%8%;%C%H$,:n(B
	     $B@.$5$l$?8e$K8F$S=P$5$l$k!%(B

%\item[\small\hook{incoming}] This is run once for each new changeset
%  that is brought into the repository from elsewhere.  Notice the
%  difference from \hook{changegroup}, which is run once per
%  \emph{group} of changesets brought in.

\item[\small\hook{incoming}] $B?7$7$$%A%'%s%8%;%C%H$,30It$+$i%j%]%8%H%j$K2C(B
	     $B$o$kKh$K8F$S=P$5$l$k!%(B\emph{group}$B$,2C$o$kKh$K8F$S=P$5$l$k%U%C(B
	     $B%/$K(B\hook{changegroup}$B%U%C%/$,$"$k!%(B

%\item[\small\hook{outgoing}] This is run after a group of changesets
%  has been transmitted from this repository.
\item[\small\hook{outgoing}] $B%j%]%8%H%j$+$i%A%'%s%8%;%C%H%0%k!<%W$,30It(B
	     $B$KAw?.$5$l$?8e$K8F$S=P$5$l$k!%(B

%\item[\small\hook{prechangegroup}] This is run before starting to
%  bring a group of changesets into the repository.
\item[\small\hook{prechangegroup}] $B%A%'%s%8%;%C%H%0%k!<%W$r%j%]%8%H%j$+(B
	     $B$i30It$K;}$A=P$9A0$K8F$S=P$5$l$k!%(B

%\item[\small\hook{precommit}] Controlling. This is run before starting
%  a commit.
\item[\small\hook{precommit}] Controlling. $B%3%_%C%H$,;O$^$kA0$K8F$S=P$5(B
	     $B$l$k!%(B

%\item[\small\hook{preoutgoing}] Controlling. This is run before
%  starting to transmit a group of changesets from this repository.
\item[\small\hook{preoutgoing}] Controlling. $B%A%'%s%8%;%C%H%0%k!<%W$r%j(B
	     $B%]%8%H%j$+$i30It$KAw?.$9$kA0$K8F$S=P$5$l$k!%(B

%\item[\small\hook{pretag}] Controlling. This is run before creating a tag.
\item[\small\hook{pretag}] Controlling. $B%?%0$,:n@.$5$l$kA0$K8F$S=P$5$l$k!%(B

%\item[\small\hook{pretxnchangegroup}] Controlling. This is run after a
%  group of changesets has been brought into the local repository from
%  another, but before the transaction completes that will make the
%  changes permanent in the repository.
\item[\small\hook{pretxnchangegroup}] Controlling. $B%A%'%s%8%;%C%H%0%k!<%W(B
	     $B$,30It$+$i%m!<%+%k%j%]%8%H%j$K2C$o$C$?8e!$1JB3E*$K5-O?$9$k$?(B
	     $B$a$N%H%i%s%6%/%7%g%s$,40N;$9$kA0$K8F$S=P$5$l$k!%(B

%\item[\small\hook{pretxncommit}] Controlling. This is run after a new
%  changeset has been created in the local repository, but before the
%  transaction completes that will make it permanent.
\item[\small\hook{pretxncommit}] Controlling. $B?7$7$$%A%'%s%8%;%C%H$,%m!<(B
	     $B%+%k%j%]%8%H%j$G:n@.$5$l$?8e!$1JB3E*$K5-O?$9$k$?$a$N%H%i%s%6(B
	     $B%/%7%g%s$,40N;$9$kA0$K8F$S=P$5$l$k!%(B

%\item[\small\hook{preupdate}] Controlling. This is run before starting
%  an update or merge of the working directory.
\item[\small\hook{preupdate}] Controlling. $B%o!<%-%s%0%G%#%l%/%H%j$N99?7(B
	     $B$^$?$O%^!<%8$,9T$o$l$kA0$K8F$S=P$5$l$k!%(B

%\item[\small\hook{tag}] This is run after a tag is created.
\item[\small\hook{tag}] $B%?%0$,:n@.$5$l$?8e$G8F$S=P$5$l$k!%(B

%\item[\small\hook{update}] This is run after an update or merge of the
%  working directory has finished.
\item[\small\hook{update}] $B%o!<%-%s%0%G%#%l%/%H%j$N99?7$+%^!<%8$,40N;$7(B
	     $B$?;~$K8F$S=P$5$l$k!%(B
\end{itemize}
%Each of the hooks whose description begins with the word
%``Controlling'' has the ability to determine whether an activity can
%proceed.  If the hook succeeds, the activity may proceed; if it fails,
%the activity is either not permitted or undone, depending on the hook.

$B%U%C%/$N$&$A!$@bL@$,(B``Controlling''$B$H$$$&8l$G;O$^$k$b$N$O!$%U%C%/$N@.H]$r(B
$BH=Dj$7!$0J8e$NF0:n$r9T$&$+$I$&$+7hDj$9$k5!G=$,$"$k!%%U%C%/$,@.8y$9$k$HF0(B
$B:n$O@h$X?J$`!%%U%C%/$,@.8y$7$J$+$C$?>l9g$O0J8e$NF0:n$O<B9T$,5v2D$5$l$J$$(B
$B$+!$F0:n$,40N;$;$:=*$k!%(B

%\section{Hooks and security}
\section{$B%U%C%/$H%;%-%e%j%F%#(B}

%\subsection{Hooks are run with your privileges}
\subsection{$B%U%C%/$O%f!<%6$N8"8B$GF0:n$9$k(B}

%When you run a Mercurial command in a repository, and the command
%causes a hook to run, that hook runs on \emph{your} system, under
%\emph{your} user account, with \emph{your} privilege level.  Since
%hooks are arbitrary pieces of executable code, you should treat them
%with an appropriate level of suspicion.  Do not install a hook unless
%you are confident that you know who created it and what it does.

$B%j%]%8%H%jFb$G(BMercurial$B%3%^%s%I$r<B9T$7!$%3%^%s%I$,%U%C%/$r8F$S=P$7$?>l(B
$B9g!$%U%C%/$O(B\emph{$BA`:n<T(B}$B$N%7%9%F%`$G!$(B\emph{$BA`:n<T(B}$B$NFC8"%l%Y%k$GF0:n$9(B
$B$k!%%U%C%/$OG$0U$N<B9T%3!<%I$J$N$G!$Aj1~$NN10U$,I,MW$G$"$k!%%U%C%/$r:n$C(B
$B$?$N$,C/$G!$$=$N%U%C%/$,2?$r$9$k$N$+$-$A$s$HM}2r$9$k$3$H$J$7$K%U%C%/$r%$(B
$B%s%9%H!<%k$7$F$O$J$i$J$$!%(B

%In some cases, you may be exposed to hooks that you did not install
%yourself.  If you work with Mercurial on an unfamiliar system,
%Mercurial will run hooks defined in that system's global \hgrc\ file.

$B<+J,$G%$%s%9%H!<%k$7$?$N$G$O$J$$%U%C%/$r<B9T$5$;$F$7$^$&$3$H$bM-$jF@$k!%(B
$BB>=j$N%7%9%F%`$N>e$G(BMercurial$B$r;H$&>l9g!$(BMercurial$B$,%7%9%F%`%o%$%I$N(B
\hgrc\ $B%U%!%$%k$GDj5A$5$l$?%U%C%/$r5/F0$9$k2DG=@-$,$"$k!%(B

%If you are working with a repository owned by another user, Mercurial
%can run hooks defined in that user's repository, but it will still run
%them as ``you''.  For example, if you \hgcmd{pull} from that
%repository, and its \sfilename{.hg/hgrc} defines a local
%\hook{outgoing} hook, that hook will run under your user account, even
%though you don't own that repository.

$BB>$N%f!<%6$,=jM-$9$k%j%]%8%H%j$G:n6H$9$k>l9g!$(BMercurial$B$O=jM-<T$N%j%]%8(B
$B%H%jFb$GDj5A$5$l$?%U%C%/$r<B9T$7F@$k$,!$<B9T8"8B$O$"$J$?$N$b$N$G9T$o$l$k!%(B
$BNc$($P$=$N%j%]%8%H%j$+$i(B\hgcmd{pull}$B$r9T$&$H$-!$%j%]%8%H%jFb$N(B
\sfilename{.hg/hgrc}$B%U%!%$%k$G%m!<%+%k$J(B\hook{outgoing}$B%U%C%/$,Dj5A$5$l$F(B
$B$$$k$H!$$"$J$?$O$=$N%j%]%8%H%j$r=jM-$7$F$$$J$$$K$b$+$+$o$i$:$=$N%U%C%/$O(B
$B$"$J$?$N8"8B$G<B9T$5$l$k!%(B

%\begin{note}
%  This only applies if you are pulling from a repository on a local or
%  network filesystem.  If you're pulling over http or ssh, any
%  \hook{outgoing} hook will run under whatever account is executing
%  the server process, on the server.
%\end{note}
\begin{note}
$B$3$l$O%m!<%+%k$J%j%]%8%H%j$d%M%C%H%o!<%/%U%!%$%k%7%9%F%`>e$N%j%]%8%H%j$+(B
 $B$i(Bpull$B$7$?>l9g$K$N$_E,MQ$5$l$k!%(Bhttp$B$^$?$O(Bssh$B$r;H$C$F(Bpull$B$7$?>l9g!$$9$Y(B
 $B$F$N(B\hook{outgoing}$B%U%C%/$O%5!<%P>e$G%5!<%P%W%m%;%9$r<B9T$7$F$$$k%"%+%&(B
 $B%s%H$N8"8B$G<B9T$5$l$k!%(B
\end{note}

%XXX To see what hooks are defined in a repository, use the
%\hgcmdargs{config}{hooks} command.  If you are working in one
%repository, but talking to another that you do not own (e.g.~using
%\hgcmd{pull} or \hgcmd{incoming}), remember that it is the other
%repository's hooks you should be checking, not your own.

XXX $B%j%]%8%H%jFb$GDj5A$5$l$F$$$k%U%C%/$r8+$k$K$O(B
\hgcmdargs{config}{hooks}$B%3%^%s%I$r;H$&!%$"$k%j%]%8%H%j$G:n6H$7$F$$$F!$?7(B
$B$7$$%3!<%I$rB>$N%j%]%8%H%j$+$iF~<j$9$k$?$a$KDL?.$r9T$&>l9g!JNc$($P(B
\hgcmd{pull}$B$+(B\hgcmd{incoming}$B$r<B9T$9$k!K(B $B!$%A%'%C%/$9$Y$-%U%C%/$O<j85$N(B
$B%j%]%8%H%j$N$b$N$G$O$J$/!$%j%b!<%H$N%j%]%8%H%j$N%U%C%/$G$"$k!%(B

%\subsection{Hooks do not propagate}
\subsection{$B%U%C%/$OEAGE$7$J$$(B}

%In Mercurial, hooks are not revision controlled, and do not propagate
%when you clone, or pull from, a repository.  The reason for this is
%simple: a hook is a completely arbitrary piece of executable code.  It
%runs under your user identity, with your privilege level, on your
%machine.

Mercurial$B$G$O!$%U%C%/$O%j%S%8%g%s4IM}$5$l$:!$%j%]%8%H%j$+$i%/%m!<%s$7$?$j(B
pull$B$7$F$bEAGE$7$J$$!%$3$&$J$C$F$$$kM}M3$OC1=c$G!$%U%C%/$OG$0U$N<B9T2DG=(B
$B%3!<%I$G$"$k$+$i$G$"$k!%%U%C%/$O$"$J$?$N%^%7%s$N>e$G$"$J$?$N%f!<%6!<(BID$B$H(B
$BFC8"%l%Y%k$GF0:n$GF0$/!%(B

%It would be extremely reckless for any distributed revision control
%system to implement revision-controlled hooks, as this would offer an
%easily exploitable way to subvert the accounts of users of the
%revision control system.

$BJ,;6%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$K%j%S%8%g%s4IM}$5$l$?%U%C%/$r<BAu$9$k(B
$B$N$O$H$F$bL5KE$G$"$k!%$3$N$h$&$J5!9=$,$"$k$H%j%S%8%g%s%3%s%H%m!<%k%7%9%F(B
$B%`$N%f!<%6%"%+%&%s%H$r56Au$9$k$h$&$J;E3]$1$r4JC1$K<B8=$G$-$F$7$^$&!%(B

%Since Mercurial does not propagate hooks, if you are collaborating
%with other people on a common project, you should not assume that they
%are using the same Mercurial hooks as you are, or that theirs are
%correctly configured.  You should document the hooks you expect people
%to use.

Mercurial$B$O%U%C%/$rEAGE$5$;$J$$$N$G!$6&DL$N%W%m%8%'%/%H$GB>$N3+H/<T$H6(NO(B
$B$7$F$$$k>l9g!$H`$i$O$"$J$?$,;H$C$F$k$N$HF1$8(BMercurial$B%U%C%/$r;H$C$F$$$k$H(B
$B2>Dj$7$?$j!$H`$i$N%j%]%8%H%j$G$b%U%C%/$,F1MM$K@5$7$/@_Dj$5$l$F$$$k$H2>Dj(B
$B$9$Y$-$G$O$J$$!%H`$i$,%U%C%/$r;H$&$h$&$KK>$`$N$G$"$l$P!$;HMQK!$K$D$$$F%I(B
$B%-%e%a%s%H$r:n@.$9$Y$-$G$"$k!%(B

%In a corporate intranet, this is somewhat easier to control, as you
%can for example provide a ``standard'' installation of Mercurial on an
%NFS filesystem, and use a site-wide \hgrc\ file to define hooks that
%all users will see.  However, this too has its limits; see below.

$B4k6HFb$N%$%s%H%i%M%C%H$G$O%3%s%H%m!<%k$O4vJ,4JC1$G$"$k!%(B NFS$B%U%!%$%k%7%9(B
$B%F%`>e$G(BMercurial$B$N(B``$BI8=`(B''$B%$%s%9%H%l!<%7%g%sNc$rDs6!$7!$$9$Y$F$N%f!<%6$,(B
$B;2>H$9$k%5%$%H%o%$%I$N(B\hgrc\ $B%U%!%$%k$rMQ0U$7!$$=$NCf$G%U%C%/$rDj5A$9$k$3(B
$B$H$,$G$-$k!%$7$+$7$3$NJ}K!$K$b2<5-$N$h$&$J7gE@$,$"$k!%(B

%\subsection{Hooks can be overridden}
\subsection{$B%U%C%/$O%*!<%P%i%$%I2DG=$G$"$k(B}

%Mercurial allows you to override a hook definition by redefining the
%hook.  You can disable it by setting its value to the empty string, or
%change its behaviour as you wish.

Mercurial$B$G$O!$%U%C%/$r:FDj5A$9$k$3$H$K$h$C$F!$4{B8$N%U%C%/Dj5A$r%*!<%P%i(B
$B%$%I$9$k$3$H$,$G$-$k!%$3$l$OJQ?t$r6u$NJ8;zNs$K$7$?$j!$5sF0$rJQ99$9$k$3$H(B
$B$G6X;_$9$k$3$H$,$G$-$k!%(B

%If you deploy a system-~or site-wide \hgrc\ file that defines some
%hooks, you should thus understand that your users can disable or
%override those hooks.

$B%U%C%/$rDj5A$7$?%7%9%F%`%o%$%I$^$?$O%5%$%H%o%$%I$N(B\hgrc\ $B%U%!%$%k$r;HMQ$7(B
$B$F$b!$%j%]%8%H%j$N%f!<%6$,%U%C%/$r6X;_$7$?$j%*!<%P%i%$%I$G$-$F$7$^$&$N$K(B
$B5$IU$/$@$m$&!%(B

%\subsection{Ensuring that critical hooks are run}
\subsection{$B%/%j%F%#%+%k$J%U%C%/$,3N<B$K<B9T$5$l$k$h$&$K$9$k(B}

%Sometimes you may want to enforce a policy that you do not want others
%to be able to work around.  For example, you may have a requirement
%that every changeset must pass a rigorous set of tests.  Defining this
%requirement via a hook in a site-wide \hgrc\ won't work for remote
%users on laptops, and of course local users can subvert it at will by
%overriding the hook.

$B;~$K$OB>$N3+H/<T$,2sHr:v$r$H$l$J$$$h$&$J%]%j%7!<$rMW@A$7$?$$>l9g$,$"$k$@(B
$B$m$&!%Nc$($P$9$Y$F$N%A%'%s%8%;%C%H$,873J$J%F%9%H%;%C%H$K%Q%9$9$k$3$H$rI,(B
$BMW$H$9$k>l9g$,9M$($i$l$k!%$3$l$r%5%$%H%o%$%I$N(B\hgrc\ $B$G%U%C%/$H$7$FDj5A(B
$B$7$?>l9g!$$3$l$O%i%C%W%H%C%W$r;H$C$F$$$k%j%b!<%H%f!<%6$K$O5!G=$7$J$$$7!$(B
$B%U%C%/$r%*!<%P%i%$%I$G$-$k$?$a!$%m!<%+%k%f!<%6$K$H$C$F$bL5;k$G$-$F$7$^$&!%(B

%Instead, you can set up your policies for use of Mercurial so that
%people are expected to propagate changes through a well-known
%``canonical'' server that you have locked down and configured
%appropriately.

$B$=$NBe$o$j!$(BMercurial$B$N;HMQ$K4X$9$k%]%j%7!<$r@_Dj$7!$E,@Z$K@_Dj$5$l!$87=E(B
$B$K4IM}$5$l$?4{CN$N(B``$B%+%N%K%+%k(B''$B%5!<%P$rDL$8$FJQ99$,GH5Z$9$k$h$&$K$9$k$3(B
$B$H$,$G$-$k!%(B

%One way to do this is via a combination of social engineering and
%technology.  Set up a restricted-access account; users can push
%changes over the network to repositories managed by this account, but
%they cannot log into the account and run normal shell commands.  In
%this scenario, a user can commit a changeset that contains any old
%garbage they want.

$B$3$l$r<B8=$9$k0lK!$O%=!<%7%c%k%(%s%8%K%"%j%s%0$H5;=Q$NAH$_9g$o$;$G9T$&J}(B
$BK!$G$"$k!%8BDj%"%/%;%9%"%+%&%s%H$r@_Dj$7!$$3$N%"%+%&%s%H$G4IM}$5$l$F$$$k(B
$B%j%]%8%H%j$KBP$7$F%f!<%6$OJQ99$r%M%C%H%o!<%/$r2p$7$F(Bpush$B$G$-$k!%$7$+$7%f!<(B
$B%6$O$3$N%"%+%&%s%H$G%m%0%$%s$7$?$j!$DL>o$N%7%'%k%3%^%s%I$r<B9T$9$k$3$H$O(B
$B$G$-$J$$!%$3$N%7%J%j%*$G$O!$%f!<%6$O$I$s$J8E$$%4%_$r4^$s$@%A%'%s%8%;%C%H(B
$B$G$b%3%_%C%H$9$k$3$H$,$G$-$k!%(B

%When someone pushes a changeset to the server that everyone pulls
%from, the server will test the changeset before it accepts it as
%permanent, and reject it if it fails to pass the test suite.  If
%people only pull changes from this filtering server, it will serve to
%ensure that all changes that people pull have been automatically
%vetted.

$BB?$/$N%f!<%6$,(Bpull$B$9$k%5!<%P$KC/$+$,%A%'%s%8%;%C%H$r(Bpush$B$7$?>l9g!$%5!<%P(B
$B$O%A%'%s%8%;%C%H$r915WE*$K<u$1F~$l$kA0$K%A%'%C%/$r9T$$!$0lO"$N%F%9%H$r%Q(B
$B%9$G$-$J$1$l$P%j%8%'%/%H$r9T$&!%%f!<%6$,$3$N%U%#%k%?%5!<%P$+$i$N$_(Bpull$B$r(B
$B9T$&$N$G$"$l$P!$A4$F$NJQ99$O<+F0E*$KA4$F8!::$5$l$F$$$k$3$H$K$J$k!%(B

%\section{Care with \texttt{pretxn} hooks in a shared-access repository}
\section{$B6&M-%"%/%;%9%j%]%8%H%j$G(B\texttt{pretxn}$B%U%C%/$r;H$&(B}

%If you want to use hooks to do some automated work in a repository
%that a number of people have shared access to, you need to be careful
%in how you do this.

$BJ#?t$N%f!<%6$,6&M-%"%/%;%9$r9T$&%j%]%8%H%j$G!$<+F02=$5$l$?:n6H$r9T$&$?$a(B
$B$K%U%C%/$r;HMQ$7$?$$$J$i!$$I$N$h$&$K9T$&$+Cm0U?<$/9M$($kI,MW$,$"$k!%(B

%Mercurial only locks a repository when it is writing to the
%repository, and only the parts of Mercurial that write to the
%repository pay attention to locks.  Write locks are necessary to
%prevent multiple simultaneous writers from scribbling on each other's
%work, corrupting the repository.

Mercurial$B$O%j%]%8%H%j$K=q$-9~$_$r9T$&$H$-$K$@$1%j%]%8%H%j$r%m%C%/$9$k!%(B
$B$^$?(BMercurial$B$N=q$-9~$_$r9T$&ItJ,$N$_$,%m%C%/$r9MN8$9$k!%=q$-9~$_%m%C%/(B
$B$O!$J#?t$NF1;~=q$-9~$_$,B>$NJQ99$r>e=q$-$7!$%j%]%8%H%j$rGKB;$9$k$N$rKI$0!%(B

%Because Mercurial is careful with the order in which it reads and
%writes data, it does not need to acquire a lock when it wants to read
%data from the repository.  The parts of Mercurial that read from the
%repository never pay attention to locks.  This lockless reading scheme
%greatly increases performance and concurrency.

Mercurial$B$O%G!<%?$NFI$_=q$-$N=g=x$rCm0U?<$/9T$&$?$a!$%j%]%8%H%j$+$i$N%G!<(B
$B%?FI$_=P$7$N:]$K%m%C%/$r<hF@$9$kI,MW$,$J$$!%(B Mercurial$B$N%j%]%8%H%j$+$iFI(B
$B$_=P$7$r9T$&ItJ,$O!$%m%C%/$rA4$/5$$K$9$kI,MW$,$J$$!%$3$N%m%C%/$J$7FI$_=P(B
$B$7$K$h$C$F!$F1;~<B9T@-$H@-G=$rBgI}$K9b$a$F$$$k!%(B

%With great performance comes a trade-off, though, one which has the
%potential to cause you trouble unless you're aware of it.  To describe
%this requires a little detail about how Mercurial adds changesets to a
%repository and reads those changes.

$B$7$+$7$J$,$i$3$N9b@-G=$O$=$l$rCN$i$J$1$l$PLdBj$r0z$-5/$3$9$"$k%H%l!<%I%*(B
$B%U$r$b$b$?$i$9!%$3$l$r@bL@$9$k$?$a$K!$(BMercurial$B$,$I$N$h$&$K%A%'%s%8%;%C%H(B
$B$r%j%]%8%H%j$KDI2C$7!$$=$l$i$rFI$_=P$9$+$N>\:Y$K?($l$J$1$l$P$J$i$J$$!%(B

%When Mercurial \emph{writes} metadata, it writes it straight into the
%destination file.  It writes file data first, then manifest data
%(which contains pointers to the new file data), then changelog data
%(which contains pointers to the new manifest data).  Before the first
%write to each file, it stores a record of where the end of the file
%was in its transaction log.  If the transaction must be rolled back,
%Mercurial simply truncates each file back to the size it was before the
%transaction began.

Mercurial$B$O%a%?%G!<%?$r(B\emph{$B=q$-9~$`(B}$B$H$-!$D>@\L\E*$N%U%!%$%k$K=q$-9~$_(B
$B$9$k!%(BMercurial$B$O$^$:%U%!%$%k%G!<%?$r=q$-9~$_!$<!$$$G!J?7$7$$%U%!%$%k%G!<(B
$B%?$N>l=j$r<($9%]%$%s%?$r4^$`!K%^%K%U%'%9%H%G!<%?$r=q$-9~$`!%$=$7$F!J?7$7(B
$B$$%^%K%U%'%9%H%G!<%?$N>l=j$r<($9%]%$%s%?$r4^$`!K%A%'%s%8%m%0%G!<%?$r=q$-(B
$B9~$`!%3F!9$N%U%!%$%k$X$N:G=i$N=q$-9~$_$NA0$K!$%U%!%$%k$NKvHx$N%l%3!<%I$r(B
$B%H%i%s%6%/%7%g%s%m%0$KJ]B8$9$k!%%H%i%s%6%/%7%g%s$,%m!<%k%P%C%/$5$l$k>l9g(B
$B$O!$(BMercurial$B$O3F!9$N%U%!%$%k$r%H%i%s%6%/%7%g%s$,;O$^$kA0$N%5%$%:$K@Z$j5M(B
$B$a$k!%(B

%When Mercurial \emph{reads} metadata, it reads the changelog first,
%then everything else.  Since a reader will only access parts of the
%manifest or file metadata that it can see in the changelog, it can
%never see partially written data.

Mercurial$B$O%a%?%G!<%?$r(B\emph{$BFI$`(B}$B;~$K$^$:%A%'%s%8%m%0$rFI$_!$<!$$$G;D$j(B
$B$NItJ,$rFI$`!%%j!<%@$O%A%'%s%8%m%0$K8=$l$k%^%K%U%'%9%H$N0lIt$^$?$O%U%!%$(B
$B%k%a%?%G!<%?$N0lIt$K$N$_%"%/%;%9$9$k$?$a!$ItJ,E*$K=q$+$l$?%G!<%?$r8+$k$3(B
$B$H$O$G$-$J$$!%(B

%Some controlling hooks (\hook{pretxncommit} and
%\hook{pretxnchangegroup}) run when a transaction is almost complete.
%All of the metadata has been written, but Mercurial can still roll the
%transaction back and cause the newly-written data to disappear.

$B$$$/$D$+$N@)8f%U%C%/!J(B\hook{pretxncommit}$B$H(B\hook{pretxnchangegroup}$B!K$O%H(B
$B%i%s%6%/%7%g%s$,$[$\40N;$7$?;~$K<B9T$5$l$k!%$9$Y$F$N%a%?%G!<%?$,=q$-9~$^(B
$B$l$k$,!$$3$N;~E@$G$b(BMercurial$B$O%H%i%s%6%/%7%g%s$r85$KLa$9$3$H$,$G$-!$$=$N(B
$B>l9g$O?7$7$/=q$+$l$?%G!<%?$O>C<:$9$k!%(B

%If one of these hooks runs for long, it opens a window of time during
%which a reader can see the metadata for changesets that are not yet
%permanent, and should not be thought of as ``really there''.  The
%longer the hook runs, the longer that window is open.

$B$3$l$i$N%U%C%/$N$&$A(B1$B$D$,D9;~4V$K$o$?$C$F<B9T$5$l$F$$$k$H!$%j!<%@$,%A%'%s(B
$B%8%;%C%H$N%a%?%G!<%?$rFI$`$3$H$N$G$-$k%?%$%`%&%#%s%I%&$,3+$/!%$3$N%A%'%s(B
$B%8%;%C%H$O$^$@1JB3E*$J$b$N$K$J$C$F$*$i$:!$=>$C$F<B:_$9$k$H9M$($k$Y$-$G$O(B
$B$J$$$b$N$G$"$k!%%U%C%/$,<B9T$5$l$F$$$k;~4V$,D9$/$J$l$P$J$k$[$I!$%?%$%`%&%#(B
$B%s%I%&$,3+$/;~4V$bD9$/$J$k!%(B

%\subsection{The problem illustrated}
\subsection{$BLdBj$N>\:Y(B}

%In principle, a good use for the \hook{pretxnchangegroup} hook would
%be to automatically build and test incoming changes before they are
%accepted into a central repository.  This could let you guarantee that
%nobody can push changes to this repository that ``break the build''.
%But if a client can pull changes while they're being tested, the
%usefulness of the test is zero; an unsuspecting someone can pull
%untested changes, potentially breaking their build.

$B<BMQ$K$*$1$k(B\hook{pretxnchangegroup}$B%U%C%/$NNI$$;HMQK!$H$7$F$O!$E~Ce$7$?(B
$BJQ99$,Cf1{$N%j%]%8%H%j$K<h$j9~$^$l$kA0$K<+F0$G%S%k%I$H%F%9%H$r9T$&$3$H$,(B
$B9M$($i$l$k!%$3$l$K$h$j!$%S%k%I$rK8$2$kJQ99$OC/$b%j%]%8%H%j$K(Bpush$B$G$-$J$$(B
$B$3$H$,3N<B$K$J$k!%%/%i%$%"%s%H$,%F%9%HCf$KJQ99$r(Bpull$B$9$k$3$H$,$G$-$l$P!$(B
$B$3$N%F%9%H$NM-MQ@-$O%<%m$K$J$C$F$7$^$&!%5?$$$r;}$?$:$KC/$+$,%F%9%H$5$l$F(B
$B$$$J$$JQ99$r(Bpull$B$G$-$k$N$G$"$l$P!$H`$i$N%S%k%I$O<:GT$9$k2DG=@-$,$"$k!%(B

%The safest technological answer to this challenge is to set up such a
%``gatekeeper'' repository as \emph{unidirectional}.  Let it take
%changes pushed in from the outside, but do not allow anyone to pull
%changes from it (use the \hook{preoutgoing} hook to lock it down).
%Configure a \hook{changegroup} hook so that if a build or test
%succeeds, the hook will push the new changes out to another repository
%that people \emph{can} pull from.

$B$3$NLdBj$X$N5;=QE*$K:G$b0BA4$J2sEz$O!$(B``$BLgHV(B''$B%j%]%8%H%j$r(B\emph{$B0lJ}8~(B}$B$K(B
$B@_Dj$9$k$3$H$G$"$k!%%j%]%8%H%j$r30It$+$i(Bpush$B$5$l$?JQ99$r<u$1<h$k$,!$C/$b(B
pull$B$G$-$J$$$h$&$K@_Dj$9$k!J(B\hook{preoutgoing}$B%U%C%/$r;H$C$F%j%]%8%H%j$r(B
$B%m%C%/$9$k!K!%(B\hook{changegroup}$B%U%C%/$r@_Dj$7!$%S%k%I$d%F%9%H$,@.8y$7$?(B
$B$H$-$K8B$C$F!$%U%C%/$,?7$?$JJQ99$r%f!<%6$N(Bpull\emph{$B$G$-$k(B}$BJL$N%j%]%8%H(B
$B%j$K(Bpush$B$9$k$h$&$K$9$k!%(B

%In practice, putting a centralised bottleneck like this in place is
%not often a good idea, and transaction visibility has nothing to do
%with the problem.  As the size of a project---and the time it takes to
%build and test---grows, you rapidly run into a wall with this ``try
%before you buy'' approach, where you have more changesets to test than
%time in which to deal with them.  The inevitable result is frustration
%on the part of all involved.

$B<B:]>e$O!$$3$N$h$&$K=8Cf$7$?%\%H%k%M%C%/$rCV$/$3$H$ONI$$9M$($H$O8@$($:!$(B
$B%H%i%s%6%/%7%g%s$N2D;k@-$OA4$/$J$$!%%W%m%8%'%/%H$N%5%$%:$*$h$S%S%k%I$H%F(B
$B%9%H$KMW$9$k;~4V$,A}2C$9$k$K=>$C$F!$$3$N$h$&$J(B``$B;vA0$K;n$9(B''$B<jK!$OJI$KFM(B
$B$-Ev$?$k!%%F%9%H$K;H$($k;~4V$G;+$-@Z$l$J$$$[$I$N%A%'%s%8%;%C%H$r;n$5$J$1(B
$B$l$P$J$i$J$/$J$k$+$i$G$"$k!%%U%i%9%H%l!<%7%g%s$,Cy$k$N$OHr$1$i$l$J$$$@$m(B
$B$&!%(B

%An approach that scales better is to get people to build and test
%before they push, then run automated builds and tests centrally
%\emph{after} a push, to be sure all is well.  The advantage of this
%approach is that it does not impose a limit on the rate at which the
%repository can accept changes.

$B$h$j%9%1!<%k$9$k<jK!$O!$3+H/<T$K(Bpush$BA0$N%S%k%I$H%F%9%H$r$5$;$k$3$H$G$"(B
$B$k!%Cf1{$G<+F0$K$h$k%S%k%I$H%F%9%H$r9T$&$N$O!$(Bpush\emph{$B8e(B}$B$K!$A4$F$KLdBj(B
$B$,$J$$$3$H$r3NG'$9$k$?$a$K9T$&!%$3$N%"%W%m!<%A$NMxE@$O%j%]%8%H%j$,JQ99$r(B
$B<u$1F~$l$k%Z!<%9$K2?$b@)8B$r2]$5$J$$$3$H$G$"$k!%(B

%\section{A short tutorial on using hooks}
\section{$B%U%C%/$N;HMQK!(B}
\label{sec:hook:simple}

%It is easy to write a Mercurial hook.  Let's start with a hook that
%runs when you finish a \hgcmd{commit}, and simply prints the hash of
%the changeset you just created.  The hook is called \hook{commit}.

Mercurial$B%U%C%/$r=q$/$N$OMF0W$$!%$3$3$G$O(B\hgcmd{commit}$B%3%^%s%I$,=*N;$7(B
$B$?:]$K!$:n@.$5$l$?%A%'%s%8%;%C%H$N%O%C%7%eCM$rI=<($9$k$/%U%C%/$r=q$$$F$_(B
$B$h$&!%$3$N%U%C%/$r(B\hook{commit}$B$H8F$V$3$H$K$9$k!%(B

\begin{figure}[ht]
  \interaction{hook.simple.init}
%  \caption{A simple hook that runs when a changeset is committed}
  \caption{$B%A%'%s%8%;%C%H$,%3%_%C%H$5$l$?;~$KF0:n$9$kC1=c$J%U%C%/(B}
  \label{ex:hook:init}
\end{figure}

%All hooks follow the pattern in example~\ref{ex:hook:init}.  You add
%an entry to the \rcsection{hooks} section of your \hgrc\.  On the left
%is the name of the event to trigger on; on the right is the action to
%take.  As you can see, you can run an arbitrary shell command in a
%hook.  Mercurial passes extra information to the hook using
%environment variables (look for \envar{HG\_NODE} in the example).

$BA4$F$N%U%C%/$ONc(B~\ref{ex:hook:init}$B$HF1$8%Q%?!<%s$K$J$k!%(B \hgrc $B%U%!%$%k$N(B
\rcsection{hooks}$B%;%/%7%g%s$K%(%s%H%j$rDI2C$9$k!%:8JU$K%H%j%,!<$H$J$k%Y%s(B
$B%H$r5-=R$7!$1&JU$KBP1~$9$k%"%/%7%g%s$r5-=R$9$k!%Nc$K<($7$?DL$j!$%U%C%/$K(B
$B$OG$0U$N%7%'%k%3%^%s%I$r=q$/$3$H$,$G$-$k!%4D6-JQ?t$r@_Dj$9$k$3$H$G(B
Mercurial$B$+$i%U%C%/$KDI2C$N>pJs$rEO$9$3$H$,$G$-$k!%!JNc$N(B
\envar{HG\_NODE}$B$r;2>H!%!K(B

%\subsection{Performing multiple actions per event}
\subsection{1$B$D$N%$%Y%s%H$KJ#?t$N%"%/%7%g%s$r9T$&(B}

%Quite often, you will want to define more than one hook for a
%particular kind of event, as shown in example~\ref{ex:hook:ext}.
%Mercurial lets you do this by adding an \emph{extension} to the end of
%a hook's name.  You extend a hook's name by giving the name of the
%hook, followed by a full stop (the ``\texttt{.}'' character), followed
%by some more text of your choosing.  For example, Mercurial will run
%both \texttt{commit.foo} and \texttt{commit.bar} when the
%\texttt{commit} event occurs.

$BNc(B~\ref{ex:hook:ext}$B$K<($7$?$h$&$K!$FCDj$N%$%Y%s%H$K(B2$B$D0J>e$N%U%C%/$rDj5A(B
$B$9$k$3$H$,I,MW$K$J$k$3$H$,B?$$$@$m$&!%(B Mercurial$B$G$O!$%U%C%/L>$N:G8e$K(B
\emph{$B3HD%;R(B}$B$rDI2C$9$k$3$H$G$3$l$,2DG=$K$J$k!%3HD%;R$rIU$1$k$K(B
$B$O!$(B``\texttt{.}'' $BJ8;z$H!$$3$l$KB3$/2?J8;z$+$+$i$J$kL>A0$r%U%C%/$K$D$1$l(B
$B$P$h$$!%Nc$($P(BMercurial$B$O(B\texttt{commit}$B%$%Y%s%H$,5/$-$?;~$K(B
\texttt{commit.foo}$B$H(B\texttt{commit.bar}$B%U%C%/$NN>J}$r8F$S=P$9!%(B

\begin{figure}[ht]
  \interaction{hook.simple.ext}
%  \caption{Defining a second \hook{commit} hook}
  \caption{2$BHVL\$N(B\hook{commit}$B%U%C%/$rDj5A$9$k(B}
  \label{ex:hook:ext}
\end{figure}

%To give a well-defined order of execution when there are multiple
%hooks defined for an event, Mercurial sorts hooks by extension, and
%executes the hook commands in this sorted order.  In the above
%example, it will execute \texttt{commit.bar} before
%\texttt{commit.foo}, and \texttt{commit} before both.

1$B$D$N%$%Y%s%H$KJ#?t$N%U%C%/$,Dj5A$5$l$F$$$k;~!$(BMercurial$B$O%U%C%/$r3HD%;R(B
$B$G%=!<%H$7!$%=!<%H$5$l$?=g=x$K=>$C$F%U%C%/$r<B9T$9$k!%>e5-$NNc$G$O(B
\texttt{commit}$B!$(B\texttt{commit.bar}$B!$(B\texttt{commit.foo}$B$N=g$K<B9T$9$k!%(B

%It is a good idea to use a somewhat descriptive extension when you
%define a new hook.  This will help you to remember what the hook was
%for.  If the hook fails, you'll get an error message that contains the
%hook name and extension, so using a descriptive extension could give
%you an immediate hint as to why the hook failed (see
%section~\ref{sec:hook:perm} for an example).

$B?7$7$$%U%C%/$rDj5A$9$k;~$K!$FbMF$r@bL@$9$k$h$&$J3HD%;R$rIU$1$k$N$O$h$$9M(B
$B$($G$"$k!%$3$&$9$k$3$H$K$h$C$F!$%U%C%/$NL\E*$,2?$J$N$+$r3P$($d$9$/$J$k!%(B
$B%U%C%/$,<:GT$7$?>l9g!$%(%i!<%a%C%;!<%8$K$O%U%C%/L>$H3HD%;R$,4^$^$l$k!%@b(B
$BL@E*$J3HD%;R$O%U%C%/$,<:GT$7$?M}M3$rCN$k$h$$<j$,$+$j$H$J$k!%!JNc(B
$B$O(B~\ref{sec:hook:perm}$B$r;2>H$N$3$H!%!K(B

%\subsection{Controlling whether an activity can proceed}
\subsection{$BF0:n$,?J9T$G$-$k$+$I$&$+@)8f$9$k(B}
\label{sec:hook:perm}

%In our earlier examples, we used the \hook{commit} hook, which is
%run after a commit has completed.  This is one of several Mercurial
%hooks that run after an activity finishes.  Such hooks have no way of
%influencing the activity itself.

$BA0$NNc$G$O%3%_%C%H$,40N;$7$?8e$K<B9T$5$l$k(B\hook{commit}$B%U%C%/$rMQ$$$?!%$3(B
$B$l$O(BMercurial$B%U%C%/$N$&$A!$F0:n$,=*N;$7$?8e$K<B9T$5$l$k$b$N$N$&$A$N(B1$B$D$G(B
$B$"$k!%$3$N$h$&$J%U%C%/$O!$(BMercurial$B$NF0:n$=$N$b$N$K1F6A$r5Z$\$5$J$$!%(B

%Mercurial defines a number of events that occur before an activity
%starts; or after it starts, but before it finishes.  Hooks that
%trigger on these events have the added ability to choose whether the
%activity can continue, or will abort.

Mercurial$B$OF0:n$N3+;OA0$d!$3+;O8e=*N;$9$k$^$G$N4V$KH/@8$9$k%$%Y%s%H$rB??t(B
$BDj5A$7$F$$$k!%$3$l$i$N%$%Y%s%H$G%H%j%,!<$5$l$k%U%C%/$O!$F0:n$rB39T$9$k$+(B
$BCfCG$9$k$+7h$a$k$3$H$,$G$-$k!%(B

%The \hook{pretxncommit} hook runs after a commit has all but
%completed.  In other words, the metadata representing the changeset
%has been written out to disk, but the transaction has not yet been
%allowed to complete.  The \hook{pretxncommit} hook has the ability to
%decide whether the transaction can complete, or must be rolled back.

\hook{pretxncommit}$B%U%C%/$O%3%_%C%H8e!$%3%_%C%H$N40N;A0$K8F$S=P$5$l$k!%(B
$B8@$$BX$($k$H!$%A%'%s%8%;%C%H$r<($9%a%?%G!<%?$,%G%#%9%/$K=q$-9~$^$l$?8e(B
$B$G!$%H%i%s%6%/%7%g%s$,40N;$9$kA0$K8F$S=P$5$l$k!%(B
\hook{pretxncommit}$B%U%C%/$O%H%i%s%6%/%7%g%s$r40N;$9$k$+!$%m!<%k%P%C%/$9(B
$B$k$+$r7hDj$9$k5!G=$,$"$k!%(B

%If the \hook{pretxncommit} hook exits with a status code of zero, the
%transaction is allowed to complete; the commit finishes; and the
%\hook{commit} hook is run.  If the \hook{pretxncommit} hook exits with
%a non-zero status code, the transaction is rolled back; the metadata
%representing the changeset is erased; and the \hook{commit} hook is
%not run.

\hook{pretxncommit}$B%U%C%/$,%9%F!<%?%9%3!<%I(B0$B$G=*N;$9$k$H%H%i%s%6%/%7%g%s(B
$B$O40N;$9$k$3$H$,$G$-!$%3%_%C%H$,=*N;$7!$(B\hook{commit}$B%U%C%/$,8F$S=P$5$l$k!%(B
\hook{pretxncommit}$B%U%C%/$,Hs(B0$B$N%9%F!<%?%9%3!<%I$G=*N;$9$k$H!$%H%i%s%6%/(B
$B%7%g%s$O%m!<%k%P%C%/$5$l!$%A%'%s%8%;%C%H$r<($9%a%?%G!<%?$O>C5n$5$l$k!%$3(B
$B$N>l9g(B\hook{commit}$B%U%C%/$O8F$S=P$5$l$J$$!%(B

\begin{figure}[ht]
  \interaction{hook.simple.pretxncommit}
%  \caption{Using the \hook{pretxncommit} hook to control commits}
  \caption{$B%3%_%C%H$r@)8f$9$k$?$a$K(B\hook{pretxncommit}$B%U%C%/$r;HMQ$9$k(B}
  \label{ex:hook:pretxncommit}
\end{figure}

%The hook in example~\ref{ex:hook:pretxncommit} checks that a commit
%comment contains a bug ID.  If it does, the commit can complete.  If
%not, the commit is rolled back.

~\ref{ex:hook:pretxncommit}$B$O%3%_%C%H%3%a%s%H$,%P%0(BID$B$r4^$`$+$r%A%'%C%/(B
$B$9$k!%$b$74^$^$l$l$P%3%_%C%H$O40N;$9$k!%4^$^$J$$>l9g$O%3%_%C%H$O%m!<%k%P%C(B
$B%/$5$l$k!%(B

%\section{Writing your own hooks}
\section{$B%*%j%8%J%k$N%U%C%/$r=q$/(B}

%When you are writing a hook, you might find it useful to run Mercurial
%either with the \hggopt{-v} option, or the \rcitem{ui}{verbose} config
%item set to ``true''.  When you do so, Mercurial will print a message
%before it calls each hook.

$B%U%C%/$r=q$/>l9g!$(BMercurial$B$r(B\hggopt{-v}$B%*%W%7%g%s$rIU$1$?$j(B
\rcitem{ui}{verbose}$B@_Dj9`L\$r(B``true''$B$K@_Dj$9$k$3$H$OLr$KN)$D!%$3$N>l(B
$B9g!$(BMercurial$B$O3F!9$N%U%C%/$r8F$VA0$K%a%C%;!<%8$rI=<($9$k!%(B

%\subsection{Choosing how your hook should run}
\subsection{$B%U%C%/$,$NF0:nJ}K!$rA*$V(B}
\label{sec:hook:lang}

%You can write a hook either as a normal program---typically a shell
%script---or as a Python function that is executed within the Mercurial
%process.

$B%U%C%/$O%7%'%k%9%/%j%W%H$N$h$&$JDL>o$N%W%m%0%i%`$H$7$F=q$/$3$H$b$G$-$k$7!$(B
Mercurial$B%W%m%;%9$NFbIt$G8F$S=P$5$l$k(BPython$B4X?t$H$7$F=q$/$3$H$b$G$-$k!%(B

%Writing a hook as an external program has the advantage that it
%requires no knowledge of Mercurial's internals.  You can call normal
%Mercurial commands to get any added information you need.  The
%trade-off is that external hooks are slower than in-process hooks.

$B%U%C%/$r30It%W%m%0%i%`$H$7$F=q$/MxE@$O(BMercurial$B$NFbItF0:n$rCN$i$J$/$F$b%U%C(B
$B%/$,=q$1$k$3$H$G$"$k!%I,MW$JDI2C$N>pJs$rF@$k$?$a$KDL>o$N(BMercurial$B%3%^%s%I(B
$B$r8F$S=P$9$3$H$,$G$-$k!%30It%U%C%/$O%W%m%;%9Fb%U%C%/$h$j$bDcB.$J$N$,%H%l!<(B
$B%I%*%U$G$"$k!%(B

%An in-process Python hook has complete access to the Mercurial API,
%and does not ``shell out'' to another process, so it is inherently
%faster than an external hook.  It is also easier to obtain much of the
%information that a hook requires by using the Mercurial API than by
%running Mercurial commands.

Python$B%W%m%;%9Fb%U%C%/$O(BMercurial API$B$X$N40A4$J%"%/%;%9$,2DG=$G$"$k!%(B
$BB>$N%W%m%;%9$r@8@.$9$k$3$H$,$J$$$?$a!$K\<AE*$K30It%U%C%/$h$j$b9bB.$G$"$k!%(B
$B%U%C%/$,I,MW$H$9$k>pJs$NBgH>$O!$(BMercurial$B%3%^%s%I$r<B9T$9$k$h$j$b(B
Mercurial API$B$r;H$C$F=8$a$kJ}$,MF0W$$!%(B

%If you are comfortable with Python, or require high performance,
%writing your hooks in Python may be a good choice.  However, when you
%have a straightforward hook to write and you don't need to care about
%performance (probably the majority of hooks), a shell script is
%perfectly fine.

Python$B$r;H$$47$l$F$$$?$j!$9b$$@-G=$,I,MW$J$i$P!$%U%C%/$r(BPython$B$G=q$/$N$,(B
$B$h$$$@$m$&!%$7$+$7=q$3$&$H$9$k$N$,C1=cL@2r$J%U%C%/$G!$!JB?$/$N%U%C%/$,$=(B
$B$&$G$"$k$h$&$K!K@-G=$K$OFC$K4X?4$,$J$$>l9g!$%7%'%k%9%/%j%W%H$H$7$F=q$$$F(B
$B$bA4$/LdBj$J$$!%(B

%\subsection{Hook parameters}
\subsection{$B%U%C%/%Q%i%a!<%?(B}
\label{sec:hook:param}

%Mercurial calls each hook with a set of well-defined parameters.  In
%Python, a parameter is passed as a keyword argument to your hook
%function.  For an external program, a parameter is passed as an
%environment variable.

Mercurial$B$O3F!9$N%U%C%/$N8F=P$7$N:]$K$-$A$s$HDj5A$5$l$?%Q%i%a!<%?$rEO(B
$B$9!%(BPython$B$G$O%Q%i%a!<%?$O%-!<%o!<%I0z?t$H$7$F%U%C%/4X?t$KEO$5$l$k!%30It(B
$B%W%m%0%i%`$K$O!$%Q%i%a!<%?$O4D6-JQ?t$H$7$FEO$5$l$k!%(B

%Whether your hook is written in Python or as a shell script, the
%hook-specific parameter names and values will be the same.  A boolean
%parameter will be represented as a boolean value in Python, but as the
%number 1 (for ``true'') or 0 (for ``false'') as an environment
%variable for an external hook.  If a hook parameter is named
%\texttt{foo}, the keyword argument for a Python hook will also be
%named \texttt{foo}, while the environment variable for an external
%hook will be named \texttt{HG\_FOO}.

$B%U%C%/$,(BPython$B$G=q$+$l$F$$$k$+!$%7%'%k%9%/%j%W%H$7$F=q$+$l$F$$$k$+$K4X$o(B
$B$i$:!$%U%C%/8GM-$N%Q%i%a!<%?L>$HCM$OF1$8$b$N$,MQ$$$i$l$k!%%V!<%k7?%Q%i%a!<(B
$B%?$O(BPython$B$G$O%V!<%kCM$H$7$F07$o$l$k$,!$30It%U%C%/$N$?$a$N4D6-JQ?t$G(B
$B$O!$(B1$B!J(B``$B??(B''$B!K$^$?$O(B0$B!J(B``$B56(B''$B!K$H$$$&?tCM$H$7$F07$o$l$k!%(B
$B%U%C%/%Q%i%a!<%?$K(B\texttt{foo}$B$H$$$&L>A0$,IU$1$i$l$F$$$k$H$-!$(BPython$B%U%C(B
$B%/$X$N%-!<%o!<%I0z?t$bF1$8(B\texttt{foo}$B$H$$$&L>A0$K$J$k!%(B
$B0lJ}!$30It%U%C%/$N$?$a$N4D6-JQ?t$G$O(B\texttt{HG\_FOO}$B$H$$$&L>A0$K$J$k!%(B

%\subsection{Hook return values and activity control}
\subsection{$B%U%C%/$NLa$jCM$HF0:n$N@)8f(B}

%A hook that executes successfully must exit with a status of zero if
%external, or return boolean ``false'' if in-process.  Failure is
%indicated with a non-zero exit status from an external hook, or an
%in-process hook returning boolean ``true''.  If an in-process hook
%raises an exception, the hook is considered to have failed.

$B@5$7$/F0:n$7$?30It%U%C%/$O%9%F!<%?%9$H$7$F%<%m$r!$%W%m%;%9Fb%U%C%/$N>l9g(B
$B$O%V!<%kCM(B``false''$B$rJV$5$J$1$l$P$J$i$J$$!%$J$s$i$+$N<:GT$,$"$C$?>l9g$O!$(B
$B30It%U%C%/$OHs%<%m$N=*N;%9%F!<%?%9$r!$%W%m%;%9Fb%U%C%/$O%V!<%kCM(B``true''
$B$rJV$9!%$b$7%W%m%;%9Fb%U%C%/$,Nc30$rH/@8$7$?>l9g$O!$%U%C%/$O<:GT$7$?$H8+(B
$B$J$5$l$k!%(B

%For a hook that controls whether an activity can proceed, zero/false
%means ``allow'', while non-zero/true/exception means ``deny''.

$BF0:n$N7QB3$r@)8f$9$k%U%C%/$N>l9g$O!$%<%m!?(Bfalse$B$O7QB3$N5v2D$r!$Hs%<(B
$B%m!?(Btrue$B!?Nc30$N>l9g$O6X;_$r0UL#$9$k!%(B

%\subsection{Writing an external hook}
\subsection{$B30It%U%C%/$r:n@.$9$k(B}

%When you define an external hook in your \hgrc\ and the hook is run,
%its value is passed to your shell, which interprets it.  This means
%that you can use normal shell constructs in the body of the hook.

$B30It%U%C%/$r(B \hgrc\ $B$GDj5A$7!$<B9T$9$k>l9g!$%U%C%/$O%7%'%k$KEO$5$l$kCM$r(B
$BJQ49$9$?$a!$%U%C%/$NK\BNItJ,$G%7%'%k%9%/%j%W%H$r5-=R$9$k$3$H$,$G$-$k!%(B

%An executable hook is always run with its current directory set to a
%repository's root directory.

$B30It%U%C%/$O>o$K%j%]%8%H%j$N%k!<%H%G%#%l%/%H%j$r%+%l%s%H%G%#%l%/%H%j$H$7(B
$B$F<B9T$5$l$k!%(B

%Each hook parameter is passed in as an environment variable; the name
%is upper-cased, and prefixed with the string ``\texttt{HG\_}''.

$B3F!9$N%U%C%/%Q%i%a!<%?$O4D6-JQ?t$H$7$FEO$5$l$k!%$9$J$o$A!$L>A0$OA4$FBgJ8(B
$B;z$K$J$j!$(B``\texttt{HG\_}''$B$H$$$&@\F,<-$,IU$1$i$l$k!%(B

%With the exception of hook parameters, Mercurial does not set or
%modify any environment variables when running a hook.  This is useful
%to remember if you are writing a site-wide hook that may be run by a
%number of different users with differing environment variables set.
%In multi-user situations, you should not rely on environment variables
%being set to the values you have in your environment when testing the
%hook.

$B%U%C%/%Q%i%a!<%?$rNc30$H$7$F!$(BMercurial$B$O%U%C%/$r<B9T$9$k:]$K4D6-JQ?t$NDj(B
$B5A$dJQ99$r9T$o$J$$!%B?$/$N%f!<%6$,<B9T$9$k%5%$%H%o%$%I$N%U%C%/$r:n@.$9$k(B
$B>l9g!$%f!<%6$,@_Dj$7$F$$$k4D6-JQ?t$O0[$J$k$3$H$r5-21$7$F$*$/$Y$-$G$"$k!%(B
$B%^%k%A%f!<%64D6-$N>l9g!$%U%C%/$r;n$9:]$K$"$J$?$,@_Dj$7$F$$$k4D6-JQ?t$K0M(B
$BB8$9$Y$-$G$O$J$$!%(B

%\subsection{Telling Mercurial to use an in-process hook}
\subsection{Mercurial$B$K%W%m%;%9Fb%U%C%/$r;H$&$h$&$K;X<($9$k(B}

%The \hgrc\ syntax for defining an in-process hook is slightly
%different than for an executable hook.  The value of the hook must
%start with the text ``\texttt{python:}'', and continue with the
%fully-qualified name of a callable object to use as the hook's value.

$B%W%m%;%9$J$$%U%C%/$rDj5A$9$k(B \hgrc\ $B9=J8$O<B9T2DG=%U%C%/$H$O6O$+$K0[$J$C(B
$B$F$$$k!%%U%C%/$NCM$OI,$:(B``\texttt{python:}''$B$G;O$^$j!$8e$K%U%C%/CM$H$7$F(B
$BMQ$$$i$l$k8F=P$72DG=%*%V%8%'%/%H$N40A4$JL>A0$,B3$+$J$1$l$P$J$i$J$$!%(B

%The module in which a hook lives is automatically imported when a hook
%is run.  So long as you have the module name and \envar{PYTHONPATH}
%right, it should ``just work''.

$B%U%C%/$,4^$^$l$k%b%8%e!<%k$O%U%C%/$,<B9T$5$l$k;~$K<+F0E*$KFI$_9~$^$l$k!%(B
$B%b%8%e!<%kL>$*$h$S(B\envar{PYTHONPATH}$B$,@5$7$$$+$.$jI,$:F0:n$9$k$O$:$G$"$k!%(B

%The following \hgrc\ example snippet illustrates the syntax and
%meaning of the notions we just described.
%\begin{codesample2}
%  [hooks]
%  commit.example = python:mymodule.submodule.myhook
%\end{codesample2}
%When Mercurial runs the \texttt{commit.example} hook, it imports
%\texttt{mymodule.submodule}, looks for the callable object named
%\texttt{myhook}, and calls it.

$B:#@bL@$7$?9=J8$H35G0$r@bL@$9$kCGJRE*$JNc$r0J2<$N(B\hgrc\ $B$K<($9!%(B
\begin{codesample2}
  [hooks]
  commit.example = python:mymodule.submodule.myhook
\end{codesample2}
Mercurial$B$,(B\texttt{commit.example}$B%U%C%/$r<B9T$9$k;~!$(B
\texttt{mymodule.submodule}$B$rFI$_9~$_!$8F=P$72DG=%*%V%8%'%/%H(B
\texttt{myhook}$B$rC5$7!$<B9T$9$k!%(B

%\subsection{Writing an in-process hook}
\subsection{$B%W%m%;%9Fb%U%C%/$r:n@.$9$k(B}

%The simplest in-process hook does nothing, but illustrates the basic
%shape of the hook API:
%\begin{codesample2}
%  def myhook(ui, repo, **kwargs):
%      pass
%\end{codesample2}
%The first argument to a Python hook is always a
%\pymodclass{mercurial.ui}{ui} object.  The second is a repository object;
%at the moment, it is always an instance of
%\pymodclass{mercurial.localrepo}{localrepository}.  Following these two
%arguments are other keyword arguments.  Which ones are passed in
%depends on the hook being called, but a hook can ignore arguments it
%doesn't care about by dropping them into a keyword argument dict, as
%with \texttt{**kwargs} above.

$B<B:]$K$O2?$b9T$o$J$$:G$bC1=c$J%W%m%;%9Fb%U%C%/$r%U%C%/(BAPI$B$N4pK\E*$J;H$$J}(B
$B$r@bL@$9$k$?$a$K<($9!%(B
\begin{codesample2}
  def myhook(ui, repo, **kwargs):
      pass
\end{codesample2}
Python$B%U%C%/$X$N:G=i$N0z?t$O>o$K(B\pymodclass{mercurial.ui}{ui}$B%*%V%8%'%/%H(B
$B$G$"$k!%(B2$BHVL\$N0z?t$O%j%]%8%H%j%*%V%8%'%/%H$G!$8=:_$N$H$3$m>o$K(B
\pymodclass{mercurial.localrepo}{localrepository}$B$N%$%s%9%?%s%9$G$"$k!%B>(B
$B$N%-!<%o!<%I0z?t$O$3$l$i$N(B2$B$D$N0z?t$KB3$/!%$3$l$i$O8F$S=P$5$l$F$$$k%U%C%/(B
$B$K0MB8$9$k$,!$%U%C%/$O%-!<%o!<%I$N<-=q$K(B\texttt{**kwargs}$B$H5-=R$9$k$3$H(B
$B$G!$I,MW$N$J$$0z?t$rL5;k$9$k$3$H$b$G$-$k!%(B

%\section{Some hook examples}
\section{$B%U%C%/$NNc(B}

%\subsection{Writing meaningful commit messages}
\subsection{$B0UL#$N$"$k%3%_%C%H%a%C%;!<%8$r=PNO$9$k(B}

%It's hard to imagine a useful commit message being very short.  The
%simple \hook{pretxncommit} hook of figure~\ref{ex:hook:msglen.go}
%will prevent you from committing a changeset with a message that is
%less than ten bytes long.

$BHs>o$KC;$$%3%_%C%H%a%C%;!<%8$,M-MQ$G$"$k$3$H$O$^$:$J$$!%(B
$B?^(B~\ref{ex:hook:msglen.go}$B$K<($9(B\hook{pretxncommit}$B$H$$$&C1=c$J%U%C%/$O(B10
$B%P%$%H0J2<$ND9$5$N%3%_%C%H%a%C%;!<%8$G%3%_%C%H$r9T$&$3$H$r6X;_$9$k!%(B

\begin{figure}[ht]
  \interaction{hook.msglen.go}
%  \caption{A hook that forbids overly short commit messages}
  \caption{$B6KC<$KC;$$%3%_%C%H%a%C%;!<%8$r6X;_$9$k%U%C%/(B}
  \label{ex:hook:msglen.go}
\end{figure}

%\subsection{Checking for trailing whitespace}
\subsection{$B$V$i2<$,$C$?6uGr$r%A%'%C%/$9$k(B}

%An interesting use of a commit-related hook is to help you to write
%cleaner code.  A simple example of ``cleaner code'' is the dictum that
%a change should not add any new lines of text that contain ``trailing
%whitespace''.  Trailing whitespace is a series of space and tab
%characters at the end of a line of text.  In most cases, trailing
%whitespace is unnecessary, invisible noise, but it is occasionally
%problematic, and people often prefer to get rid of it.

$B%3%_%C%H$K4XO"$7$?%U%C%/$N6=L#?<$$;HMQK!$N0l$D$K$h$j4qNo$J%3!<%I$r=q$/<j(B
$B=u$1$,$"$k!%(B ``$B4qNo$J%3!<%I(B''$B$N$4$/C1=c$JNc$O!$Nc$($P!$?7$?$J$V$i2<$,$C$?(B
$B6uGr$r4^$`9T$r4^$^$J$$$b$N$G$"$k!%$V$i2<$,$C$?6uGr$H$O!$9TKv$N0lO"$N%9%Z!<(B
$B%9$d%?%V$G$"$k!%$[$H$s$I$N>l9g!$$V$i2<$,$C$?6uGr$OITI,MW$J8+$($J$$%N%$%:(B
$B$G$"$k$,!$LdBj$r0z$-5/$3$9>l9g$b$"$j!$=|5n$7$?$,$k?M$,B?$$!%(B

%You can use either the \hook{precommit} or \hook{pretxncommit} hook to
%tell whether you have a trailing whitespace problem.  If you use the
%\hook{precommit} hook, the hook will not know which files you are
%committing, so it will have to check every modified file in the
%repository for trailing white space.  If you want to commit a change
%to just the file \filename{foo}, but the file \filename{bar} contains
%trailing whitespace, doing a check in the \hook{precommit} hook will
%prevent you from committing \filename{foo} due to the problem with
%\filename{bar}.  This doesn't seem right.

$B$V$i2<$,$j6uGr$NLdBj$rD>$9$?$a$K(B\hook{precommit}$B%U%C%/$d(B
\hook{pretxncommit}$B%U%C%/$rMQ$$$k$3$H$,$G$-$k!%(B\hook{precommit}$B%U%C%/$r;H(B
$B$&>l9g!$$I$N%U%!%$%k$r%3%_%C%H$9$k$N$+%U%C%/$OCN$k$3$H$,$J$$!%$=$N$?$a!$(B
$B%j%]%8%H%j$GJQ99$5$l$?%U%!%$%k$9$Y$F$K$D$$$F$V$i2<$,$j6uGr$r%A%'%C%/$9$k(B
$BI,MW$,$"$k!%(B \filename{foo}$B$H$$$&%U%!%$%k$r%3%_%C%H$7$?$$(B
$B$,!$(B\filename{bar}$B%U%!%$%k$,$V$i2<$,$j6uGr$r4^$s$G$$$k>l(B
$B9g!$(B\hook{precommit}$B%U%C%/$G%A%'%C%/$r9T$&$H!$%U%!%$%k(B\filename{bar}$B$NLd(B
$BBj$N$?$a$K(B\filename{foo}$B$N%3%_%C%H$,$G$-$J$/$J$k!%$3$l$O@5$7$$5sF0$H$O8@(B
$B$($J$$!%(B

%Should you choose the \hook{pretxncommit} hook, the check won't occur
%until just before the transaction for the commit completes.  This will
%allow you to check for problems only the exact files that are being
%committed.  However, if you entered the commit message interactively
%and the hook fails, the transaction will roll back; you'll have to
%re-enter the commit message after you fix the trailing whitespace and
%run \hgcmd{commit} again.

\hook{pretxncommit}$B%U%C%/$rA*$S!$%A%'%C%/$,%3%_%C%H40N;%H%i%s%6%/%7%g%s$N(B
$BD>A0$^$G5/$-$J$$$h$&$K$9$Y$-$G$"$k!%$3$l$K$h$j!$%3%_%C%H$5$l$h$&$H$9$k%U%!(B
$B%$%k$@$1$r%A%'%C%/$9$k$3$H$,$G$-$k$h$&$K$J$k!%$7$+$7$J$,$i!$%3%_%C%H%a%C(B
$B%;!<%8$rBPOCE*$KF~NO$7!$%3%_%C%H$,<:GT$9$k$H%H%i%s%6%/%7%g%s$O%m!<%k%P%C(B
$B%/$9$k$?$a!$$V$i2<$,$j6uGr$r=$@5$7!$(B\hgcmd{commit}$B$r:F$S<B9T$7!$%3%_%C%H(B
$B$9$k:]$K%3%_%C%H%a%C%;!<%8$r:FF~NO$7$J$1$l$P$J$i$J$$!%(B

\begin{figure}[ht]
  \interaction{hook.ws.simple}
%  \caption{A simple hook that checks for trailing whitespace}
 \caption{$B$V$i2<$,$C$?6uGr$r%A%'%C%/$9$kC1=c$J%U%C%/(B}
  \label{ex:hook:ws.simple}
\end{figure}

%Figure~\ref{ex:hook:ws.simple} introduces a simple \hook{pretxncommit}
%hook that checks for trailing whitespace.  This hook is short, but not
%very helpful.  It exits with an error status if a change adds a line
%with trailing whitespace to any file, but does not print any
%information that might help us to identify the offending file or
%line.  It also has the nice property of not paying attention to
%unmodified lines; only lines that introduce new trailing whitespace
%cause problems.

$B?^(B~\ref{ex:hook:ws.simple}$B$O(B\hook{pretxncommit}$B$H$$$&$V$i2<$,$j6uGr$r%A%'%C(B
$B%/$9$kC1=c$J%U%C%/$rF3F~$7$F$$$k!%$3$N%U%C%/$OC;$$$,!$$=$l$[$IM-MQ$G$O$J(B
$B$$!%99?7$,$V$i2<$,$j6uGr$r4^$`9T$r$I$N%U%!%$%k$KDI2C$7$F$b!$$3$N%U%C%/$O(B
$B%(%i!<%9%F!<%?%9$H6&$K=*N;$9$k$,!$LdBj$N$"$k%U%!%$%k$d9T$rFCDj$9$k$?$a$N(B
$B>pJs$O0l@ZI=<($7$J$$!%$3$N%U%C%/$OJQ99$N$J$$9T$K$OA4$/4X?4$r;}$?$J$$$H$$(B
$B$&NI$$@-<A$b;}$C$F$$$k!%?75,$K$V$i2<$,$j6uGr$r2C$($kLdBj$N$"$k9T$N$_$r8!(B
$B::$9$k!%(B

\begin{figure}[ht]
  \interaction{hook.ws.better}
%  \caption{A better trailing whitespace hook}
  \caption{$B$V$i2<$,$j6uGr$r%A%'%C%/$9$k%U%C%/$N2~NIHG(B}
  \label{ex:hook:ws.better}
\end{figure}

%The example of figure~\ref{ex:hook:ws.better} is much more complex,
%but also more useful.  It parses a unified diff to see if any lines
%add trailing whitespace, and prints the name of the file and the line
%number of each such occurrence.  Even better, if the change adds
%trailing whitespace, this hook saves the commit comment and prints the
%name of the save file before exiting and telling Mercurial to roll the
%transaction back, so you can use
%\hgcmdargs{commit}{\hgopt{commit}{-l}~\emph{filename}} to reuse the
%saved commit message once you've corrected the problem.

$B?^(B~\ref{ex:hook:ws.better}$B$O$+$J$jJ#;($@$,!$$h$jM-MQ$G$"$k!%$3$N%U%C%/$OE}(B
$B9g7A<0$N(Bdiff$B$r%Q!<%9$7!$$V$i2<$,$j6uGr$r4^$`%i%$%s$rC5$9!%$=$7$F8+$D$1$k(B
$B$H%U%!%$%kL>$H9THV9f$rI=<($9$k!%$5$i$KJQ99$,$V$i2<$,$j6uGr$rDI2C$9$k$H!$(B
$B$3$N%U%C%/$O%3%_%C%H%3%a%s%H$rJ]B8$7!$=*N;A0$KJ]B8%U%!%$%k$NL>A0$rI=<($9(B
$B$k!%$=$7$F(BMercurial$B$K%H%i%s%6%/%7%g%s$r%m!<%k%P%C%/$9$k$3$H$r;X<($9$k!%Ld(B
$BBj$r=$@5$7$?8e$GJ]B8$5$l$?%3%_%C%H%a%C%;!<%8$r;H$&$K$O(B
\hgcmdargs{commit}{\hgopt{commit}{-l}~\emph{filename}}$B$H$9$l$P$h$$!%(B

%As a final aside, note in figure~\ref{ex:hook:ws.better} the use of
%\command{perl}'s in-place editing feature to get rid of trailing
%whitespace from a file.  This is concise and useful enough that I will
%reproduce it here.

$B:G8e$K!$?^(B~\ref{ex:hook:ws.better}$B$N$h$&$K%U%!%$%k$+$i$V$i2<$,$j6uGr$r=|5n(B
$B$9$k$?$a$K(B\command{perl}$B%3%^%s%I$N%$%s%W%l%$%9JT=85!G=$rMQ$$$k!%$3$l$O$3(B
$B$3$G:F8=$9$k$KEv$?$C$F==J,C;$/$+$DM-8z$G$"$k!%(B

\begin{codesample2}
  perl -pi -e 's,\\s+\$,,' filename
\end{codesample2}

%\section{Bundled hooks}
\section{$BAH$_9g$o$;%U%C%/(B}

%Mercurial ships with several bundled hooks.  You can find them in the
%\dirname{hgext} directory of a Mercurial source tree.  If you are
%using a Mercurial binary package, the hooks will be located in the
%\dirname{hgext} directory of wherever your package installer put
%Mercurial.

Mercurial$B$K$O$$$/$D$+$N%U%C%/$,F1:-$5$l$F$$$k!%%U%C%/$O(BMercurial$B%=!<%9%D(B
$B%j!<$N(B\dirname{hgext}$B%G%#%l%/%H%j$K$"$k!%(B Mercurial$B$N%P%$%J%j%Q%C%1!<%8$r(B
$B;HMQ$7$F$$$k$N$G$"$l$P!$%U%C%/$O%Q%C%1!<%8%$%s%9%H!<%i$,(BMercurial$B$r%$%s%9(B
$B%H!<%k$7$?%G%#%l%/%H%jFb$N(B\dirname{hgext}$B%G%#%l%/%H%j$K$"$k$O$:$@!%(B

%\subsection{\hgext{acl}---access control for parts of a repository}
\subsection{\hgext{acl}---$B%j%]%8%H%j$NItJ,$KBP$9$k%"%/%;%9%3%s%H%m!<%k(B}

%The \hgext{acl} extension lets you control which remote users are
%allowed to push changesets to a networked server.  You can protect any
%portion of a repository (including the entire repo), so that a
%specific remote user can push changes that do not affect the protected
%portion.

\hgext{acl}$B%(%/%9%F%s%7%g%s$O!$%j%b!<%H%f!<%6$K%A%'%s%8%;%C%H$r%M%C%H%o!<(B
$B%/@\B3$5$l$?%5!<%P$K%W%C%7%e$G$-$k$h$&$K$9$k!%FCDj$N%j%b!<%H%f!<%6$,J]8n(B
$B$5$l$?0J30$NItJ,$NJQ99$r%W%C%7%e$G$-$k$h$&$K%j%]%8%H%j$NG$0U$NItJ,!JA4BN(B
$B$r$b4^$`!K$rJ]8n$9$k$3$H$,$G$-$k!%(B

%This extension implements access control based on the identity of the
%user performing a push, \emph{not} on who committed the changesets
%they're pushing.  It makes sense to use this hook only if you have a
%locked-down server environment that authenticates remote users, and
%you want to be sure that only specific users are allowed to push
%changes to that server.

$B$3$N%(%/%9%F%s%7%g%s$O%f!<%6$,%W%C%7%e$r9T$&:]$K!$C/$,%A%'%s%8%;%C%H$r%3(B
$B%_%C%H(B\emph{$B$G$-$J$$(B}$B$h$&$K$9$k$3$H$G%"%/%;%9%3%s%H%m!<%k$r<BAu$7$F$$$k!%(B
$B$3$N%U%C%/$O!$%j%b!<%H%f!<%6$NG'>Z$r9T$&J]8n$5$l$?%5!<%P4D6-$G!$;XDj$5$l(B
$B$?%f!<%6$@$1$,JQ99$r%5!<%P$K%W%C%7%e$G$-$k$h$&$K$7$?$$>l9g$K$N$_0UL#$r$J(B
$B$9!%(B

%\subsubsection{Configuring the \hook{acl} hook}
\subsubsection{\hook{acl}$B%U%C%/$N@_Dj(B}

%In order to manage incoming changesets, the \hgext{acl} hook must be
%used as a \hook{pretxnchangegroup} hook.  This lets it see which files
%are modified by each incoming changeset, and roll back a group of
%changesets if they modify ``forbidden'' files.  Example:
%\begin{codesample2}
%  [hooks]
%  pretxnchangegroup.acl = python:hgext.acl.hook
%\end{codesample2}

\hgext{acl}$B%U%C%/$r!$E~Ce$9$k%A%'%s%8%;%C%H$r4IM}$9$k$?$a$K;H$&$?$a$K$O!$(B
\hook{pretxnchangegroup}$B%U%C%/$H$7$FMQ$$$kI,MW$,$"$k!%$3$N%U%C%/$O!$3F!9(B
$B$N%A%'%s%8%;%C%H$G$I$N%U%!%$%k$,JQ99$5$l$?$N$+$r%A%'%C%/$7!$JQ996X;_$N%U%!(B
$B%$%k$XJQ99$,$"$C$?>l9g$O%A%'%s%8%;%C%H$r%m!<%k%P%C%/$9$k!%Nc!'(B
\begin{codesample2}
  [hooks]
  pretxnchangegroup.acl = python:hgext.acl.hook
\end{codesample2}

%The \hgext{acl} extension is configured using three sections.

\hgext{acl}$B%(%/%9%F%s%7%g%s$O(B3$B$D$N%;%/%7%g%s$G@_Dj$5$l$k!%(B

%The \rcsection{acl} section has only one entry, \rcitem{acl}{sources},
%which lists the sources of incoming changesets that the hook should
%pay attention to.  You don't normally need to configure this section.
%\begin{itemize}
%\item[\rcitem{acl}{serve}] Control incoming changesets that are arriving
%  from a remote repository over http or ssh.  This is the default
%  value of \rcitem{acl}{sources}, and usually the only setting you'll
%  need for this configuration item.
%\item[\rcitem{acl}{pull}] Control incoming changesets that are
%  arriving via a pull from a local repository.
%\item[\rcitem{acl}{push}] Control incoming changesets that are
%  arriving via a push from a local repository.
%\item[\rcitem{acl}{bundle}] Control incoming changesets that are
%  arriving from another repository via a bundle.
%\end{itemize}

\rcsection{acl}$B%;%/%7%g%s$O!$(B\rcitem{acl}{sources}$B$H$$$&%(%s%H%j(B1$B$D$r;}(B
$B$D!%$3$N%(%s%H%j$G%U%C%/$,4F;k$9$Y$-E~Ce%A%'%s%8%;%C%HFb%=!<%9(B
$B$rNs5s$9$k!%(B
\begin{itemize}
\item[\rcitem{acl}{serve}] $B%j%b!<%H%j%]%8%H%j$+$i(Bhttp$B$^$?$O(Bssh$B$r;H$C$FE~(B
	     $BCe$9$k%A%'%s%8%;%C%H$r@)8f$9$k!%(B\rcitem{acl}{sources}$B$N%G%U%)(B
	     $B%k%HCM$G!$DL>o$O$3$N@_DjFb$GM#0l@_Dj$9$kI,MW$N$"$k9`L\$G$"(B
	     $B$k!%(B
\item[\rcitem{acl}{pull}] $B%m!<%+%k%j%]%8%H%j$+$i(Bpull$B$7$?%A%'%s%8%;%C%H$r(B
	     $B@)8f$9$k!%(B
\item[\rcitem{acl}{push}] $B%m!<%+%k%j%]%8%H%j$+$i(Bpush$B$7$?%A%'%s%8%;%C%H$r(B
	     $B@)8f$9$k!%(B
\item[\rcitem{acl}{bundle}] $BJL$N%j%]%8%H%j$+$i%P%s%I%k$K$h$C$FE~Ce$7$?%A%'(B
	     $B%s%8%;%C%H$r@)8f$9$k!%(B
\end{itemize}

%The \rcsection{acl.allow} section controls the users that are allowed to
%add changesets to the repository.  If this section is not present, all
%users that are not explicitly denied are allowed.  If this section is
%present, all users that are not explicitly allowed are denied (so an
%empty section means that all users are denied).

\rcsection{acl.allow}$B%;%/%7%g%s$O%A%'%s%8%;%C%H$N%j%]%8%H%j$X$NDI2C$r5v(B
$B2D$5$l$F$$$k%f!<%6$r@_Dj$9$k!%$3$N%;%/%7%g%s$,B8:_$7$J$$>l9g!$L@<(E*$K5q(B
$BH]$5$l$F$$$J$$$9$Y$F$N%f!<%6$O5v2D$5$l$k!%$3$N%;%/%7%g%s$,B8:_$9$k>l9g!$(B
$BL@<(E*$K5v2D$5$l$F$$$J$$$9$Y$F$N%f!<%6$O5qH]$5$l$k!%!J$9$J$o$A!$6u$N%;%/(B
$B%7%g%s$O$9$Y$F$N%f!<%6$N5qH]$H$$$&0UL#$K$J$k!%!K(B

%The \rcsection{acl.deny} section determines which users are denied
%from adding changesets to the repository.  If this section is not
%present or is empty, no users are denied.

\rcsection{acl.deny}$B%;%/%7%g%s$O!$%j%]%8%H%j$X$N%A%'%s%8%;%C%HDI2C$r5qH](B
$B$9$k%f!<%6$r@_Dj$9$k!%$3$N%;%/%7%g%s$,B8:_$7$J$$$+!$6u$N>l9g$O$I$N%f!<%6(B
$B$b5qH]$5$l$J$$!%(B

%The syntaxes for the \rcsection{acl.allow} and \rcsection{acl.deny}
%sections are identical.  On the left of each entry is a glob pattern
%that matches files or directories, relative to the root of the
%repository; on the right, a user name.

\rcsection{acl.allow}$B$H(B\rcsection{acl.deny}$B%;%/%7%g%s$N9=J8$OF10l$G$"$k!%(B
$B3F!9$N%(%s%H%j$N:8JU$O%U%!%$%k$^$?$O%G%#%l%/%H%j$K%^%C%A$9$k(Bglob$B%Q%?!<%s(B
$B$G!$%j%]%8%H%j%k!<%H$+$i$NAjBP%Q%9$G$"$k!%1&JU$O%f!<%6L>$G$"$k!%(B

%In the following example, the user \texttt{docwriter} can only push
%changes to the \dirname{docs} subtree of the repository, while
%\texttt{intern} can push changes to any file or directory except
%\dirname{source/sensitive}.
%\begin{codesample2}
%  [acl.allow]
%  docs/** = docwriter
%
%  [acl.deny]
%  source/sensitive/** = intern
%\end{codesample2}

$B0J2<$NNc$G$O!$(B\texttt{docwriter}$B$H$$$&%f!<%6$O!$%j%]%8%H%j$N(B
\dirname{docs}$B%5%V%D%j!<$K$7$+(Bpush$B$G$-$J$$!%$^$?(B\texttt{intern}$B$O(B
\dirname{source/sensitive}$B0J30$J$i$P$I$N%G%#%l%/%H%j$N$I$N%U%!%$%k$K$bJQ(B
$B99$r(Bpush$B$9$k$3$H$,$G$-$k!%(B
\begin{codesample2}
  [acl.allow]
  docs/** = docwriter

  [acl.deny]
  source/sensitive/** = intern
\end{codesample2}

%\subsubsection{Testing and troubleshooting}
\subsubsection{$B%F%9%H$HLdBj2r7h(B}

%If you want to test the \hgext{acl} hook, run it with Mercurial's

%debugging output enabled.  Since you'll probably be running it on a
%server where it's not convenient (or sometimes possible) to pass in
%the \hggopt{--debug} option, don't forget that you can enable
%debugging output in your \hgrc:
%\begin{codesample2}
%  [ui]
%  debug = true
%\end{codesample2}
%With this enabled, the \hgext{acl} hook will print enough information
%to let you figure out why it is allowing or forbidding pushes from
%specific users.

\hgext{acl}$B%U%C%/$r%F%9%H$7$?$$>l9g$O!$(BMercurial$B$N%G%P%C%0=PNO$rM-8z$K$7(B
$B$F<B9T$9$k$HNI$$!%%5!<%P>e$G<B9T$9$k$N$G$"$l$P!"(B\hggopt{--debug}$B%*%W%7%g(B
$B%s$rEO$9$N$OITJX$G$"$C$?$j!"IT2DG=$G$"$C$?$j$9$k$3$H$,$"$k!#$3$N$?$a!"%G(B
$B%P%C%0=PNO$O(B \hgrc $B$G$bM-8z$K$G$-$k$3$H$r5-21$7$F$*$/$Y$-$G$"$k!%(B
\begin{codesample2}
  [ui]
  debug = true
\end{codesample2}
$B%G%P%C%0=PNO$,M-8z$N>l9g!$(B\hgext{acl}$B%U%C%/$O!$FCDj$N%f!<%6$r5v2D$"$k$$(B
$B$O5qH]$7$?M}M3$rCN$k$N$K==J,$J>pJs$r=PNO$9$k!%(B

%\subsection{\hgext{bugzilla}---integration with Bugzilla}
\subsection{\hgext{bugzilla}---Bugzilla$B$H$N7k9g(B}

%The \hgext{bugzilla} extension adds a comment to a Bugzilla bug
%whenever it finds a reference to that bug ID in a commit comment.  You
%can install this hook on a shared server, so that any time a remote
%user pushes changes to this server, the hook gets run.

\hgext{bugzilla}$B%(%/%9%F%s%7%g%s$O!$(BBugzilla$B$G4IM}$5$l$F$$$k%P%0$X!$%3%_%C(B
$B%H%3%a%s%H$NCf$G%P%0(BID$B$r;2>H$7$F$$$k>l9g%3%a%s%H$rDI2C$9$k!%(B
$B$3$N%U%C%/$O6&M-%5!<%P$K$b%$%s%9%H!<%k$G$-$k$N$G!$%j%b!<%H%f!<%6$,(B
$BJQ99$r(Bpush$B$7$?>l9g$K$bF0:n$9$k!%(B

%It adds a comment to the bug that looks like this (you can configure
%the contents of the comment---see below):
%\begin{codesample2}
%  Changeset aad8b264143a, made by Joe User <[e-mail]> 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
%\end{codesample2}
%The value of this hook is that it automates the process of updating a
%bug any time a changeset refers to it.  If you configure the hook
%properly, it makes it easy for people to browse straight from a
%Bugzilla bug to a changeset that refers to that bug.

$B$3$N%U%C%/$O<!$N$h$&$K%P%0$X%3%a%s%H$rDI2C$9$k!%!J%3%a%s%H$NFbMF$O@_Dj2D(B
$BG=$G$"$k!%$3$l$K$D$$$F$O2<5-$r;2>H!%!K(B
\begin{codesample2}
  Changeset aad8b264143a, made by Joe User <[e-mail]> 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
\end{codesample2}
$B$3$N%U%C%/$O!$%A%'%s%8%;%C%H$,%P%0$r;2>H$7$?>l9g!$%P%0$N99?7$r<+F02=$G$-(B
$B$k$H$3$m$K2ACM$,$"$k!%$3$N%U%C%/$r$-$A$s$H@_Dj$9$l$P!$(BBugzilla$B%P%0$r1\Mw(B
$B$7$F$$$k%f!<%6$,!$%P%0$+$iD>$A$K4X78$9$k%A%'%s%8%;%C%H$r;2>H$G$-$k$h$&$K(B
$B$J$k!%(B

%You can use the code in this hook as a starting point for some more
%exotic Bugzilla integration recipes.  Here are a few possibilities:
%\begin{itemize}
%\item Require that every changeset pushed to the server have a valid
%  bug~ID in its commit comment.  In this case, you'd want to configure
%  the hook as a \hook{pretxncommit} hook.  This would allow the hook
%  to reject changes that didn't contain bug IDs.
%\item Allow incoming changesets to automatically modify the
%  \emph{state} of a bug, as well as simply adding a comment.  For
%  example, the hook could recognise the string ``fixed bug 31337'' as
%  indicating that it should update the state of bug 31337 to
%  ``requires testing''.
%\end{itemize}

$B$3$N%U%C%/$N%3!<%I$r=PH/E@$H$7$F!$JL$N(BBugzilla$B$H$N7k9g$r9T$&$3$H$b2DG=(B
$B$G$"$k!%$$$/$D$+$NNc$r5s$2$k!'(B
\begin{itemize}
 \item $B%5!<%P$K%W%C%7%e$5$l$?%A%'%s%8%;%C%H$9$Y$F$K%3%_%C%H%3%a%s%H$KM-8z(B
       $B$J%P%0(BID$B$,$"$k$3$H$rMW5a$9$k!%$3$N>l9g!$%U%C%/$r(B
       \hook{pretxncommit}$B%U%C%/$H$7$F@_Dj$9$kI,MW$,$"$k!%$3$l$K$h$C$F!$(B
       $B%P%0(BID$B$r4^$^$J$$JQ99$r5qH]$9$k$3$H$,$G$-$k!%(B
 \item $BE~Ce$9$k%A%'%s%8%;%C%H$K!$%3%a%s%HDI2C$K2C$($F!$%P%0$N(B\emph{$B%9%F!<(B
       $B%H(B}$B$r<+F0E*$KJQ99$9$k$h$&$K$G$-$k!%Nc$($P!$%U%C%/$,(B``fixed bug
       31337''$B$N$h$&$JJ8;zNs$rG'<1$7$F!$(Bbug 31337$B$N%9%F!<%H$r(B``requires
       testing''$B$KJQ99$9$k$J$I$,9M$($i$l$k!%(B
\end{itemize}

%\subsubsection{Configuring the \hook{bugzilla} hook}
\subsubsection{\hook{bugzilla}$B%U%C%/$N@_Dj(B}
\label{sec:hook:bugzilla:config}

%You should configure this hook in your server's \hgrc\ as an
%\hook{incoming} hook, for example as follows:
%\begin{codesample2}
%  [hooks]
%  incoming.bugzilla = python:hgext.bugzilla.hook
%\end{codesample2}

$B$3$N%U%C%/$O<!$NNc$N$h$&$K%5!<%P>e$N(B\hgrc\ $B$G(B\hook{incoming}$B%U%C%/$H@_Dj(B
$B$9$Y$-$G$"$k!%(B
\begin{codesample2}
  [hooks]
  incoming.bugzilla = python:hgext.bugzilla.hook
\end{codesample2}

%Because of the specialised nature of this hook, and because Bugzilla
%was not written with this kind of integration in mind, configuring
%this hook is a somewhat involved process.

$B$3$N%U%C%/$NFCJL$J@-<A!$(BBugzilla$B$,$3$N$h$&$J7k9g$rG0F,$K=q$+$l$F$$$J$$$3(B
$B$H$K$h$C$F!$$3$N%U%C%/$N@_Dj$OJ#;($J%W%m%;%9$H$J$k!%(B

%Before you begin, you must install the MySQL bindings for Python on
%the host(s) where you'll be running the hook.  If this is not
%available as a binary package for your system, you can download it
%from~\cite{web:mysql-python}.

$B@_Dj$r3+;O$9$kA0$K!$%U%C%/$r<B9T$9$k%[%9%H>e$G(BPython$BMQ$N(BMySQL$B%P%$%s%G%#%s(B
$B%0$r%$%s%9%H!<%k$9$kI,MW$,$"$k!%<B9T4D6-MQ$K%P%$%J%j%Q%C%1!<%8$,MQ0U$5$l(B
$B$F$$$J$1$l$P!$%=!<%9%U%!%$%k$r(B\cite{web:mysql-python}$B$+$i%@%&%s%m!<%I$9$k(B
$B$3$H$,$G$-$k!%(B

%Configuration information for this hook lives in the
%\rcsection{bugzilla} section of your \hgrc.
$B$3$N%U%C%/$N@_Dj>pJs$O!$(B\hgrc $B%U%!%$%k$N(B\rcsection{bugzilla}$B%;%/%7%g%s$K(B
$B$"$k!%(B
\begin{itemize}
%\item[\rcitem{bugzilla}{version}] The version of Bugzilla installed on
%  the server.  The database schema that Bugzilla uses changes
%  occasionally, so this hook has to know exactly which schema to use.
%  At the moment, the only version supported is \texttt{2.16}.
 \item[\rcitem{bugzilla}{version}] $B%5!<%P$X%$%s%9%H!<%k$5$l$?(BBugzilla$B$N%P!<(B
	      $B%8%g%s!%(BBugzilla$B$N;HMQ$9$k%G!<%?%Y!<%9$N%9%-!<%^$O;~$KJQ99(B
	      $B$5$l$k$?$a!$%U%C%/$O$I$N%9%-!<%^$,;HMQ$5$l$k$N$+$rCN$kI,MW(B
	      $B$,$"$k!%8=;~E@$G$O(BBugzilla\texttt{2.16}$B$@$1$,%5%]!<%H$5$l(B
	      $B$F$$$k!%(B

%\item[\rcitem{bugzilla}{host}] The hostname of the MySQL server that
%  stores your Bugzilla data.  The database must be configured to allow
%  connections from whatever host you are running the \hook{bugzilla}
%  hook on.
 \item[\rcitem{bugzilla}{host}] Bugzilla$B%G!<%?$r3JG<$7$F$$$k(BMySQL$B%5!<%P$N(B
	      $B%[%9%H%M!<%`!%%G!<%?%Y!<%9$O(B\hook{bugzilla}$B%U%C%/$r<B9T$9(B
	      $B$k%[%9%H$+$i@\B32DG=$K@_Dj$5$l$F$$$J$1$l$P$J$i$J$$!%(B

%\item[\rcitem{bugzilla}{user}] The username with which to connect to
%  the MySQL server.  The database must be configured to allow this
%  user to connect from whatever host you are running the
%  \hook{bugzilla} hook on.  This user must be able to access and
%  modify Bugzilla tables.  The default value of this item is
%  \texttt{bugs}, which is the standard name of the Bugzilla user in a
%  MySQL database.
 \item[\rcitem{bugzilla}{user}] MySQL$B%5!<%P$K@\B3$9$k%f!<%6L>!%%G!<%?%Y!<(B
	      $B%9$O(B\hook{bugzilla}$B%U%C%/$r<B9T$9$k%[%9%H>e$+$i$3$N%f!<%6$N(B
	      $B@\B3$r5v2D$9$k$h$&$K@_Dj$5$l$F$$$J$1$l$P$J$i$J$$!%$3$N%f!<(B
	      $B%6$O(BBugzilla$B%F!<%V%k$K%"%/%;%9$7!$JQ99$G$-$k8"8B$,$J$1$l$P(B
	      $B$J$i$J$$!%$3$N9`L\$N%G%U%)%k%HCM$O(BMySQL$B%G!<%?%Y!<%9$G$N(B
	      Bugzilla$B%f!<%6$NI8=`L>(B\texttt{bugs}$B$G$"$k!%(B

%\item[\rcitem{bugzilla}{password}] The MySQL password for the user you
%  configured above.  This is stored as plain text, so you should make
%  sure that unauthorised users cannot read the \hgrc\ file where you
%  store this information.
 \item[\rcitem{bugzilla}{password}] $B>e5-$N%f!<%6$N(BMySQL$B%Q%9%o!<%I!%J?J8$G(B
	      $BJ]B8$5$l$k$?$a!$8"8B$N$J$$%f!<%6$,$3$N(B\hgrc\ $B%U%!%$%k$r3N<B(B
	      $B$KFI$a$J$$$h$&$K$7$F$*$/I,MW$,$"$k!%(B

%\item[\rcitem{bugzilla}{db}] The name of the Bugzilla database on the
%  MySQL server.  The default value of this item is \texttt{bugs},
%  which is the standard name of the MySQL database where Bugzilla
%  stores its data.
 \item[\rcitem{bugzilla}{db}] MySQL$B%5!<%P>e$N(BBugzilla$B%G!<%?%Y!<%9$NL>A0!%(B
	      $B$3$N9`L\$N%G%U%)%k%HCM$O(B\texttt{bugs}$B$3$N9`L\$N%G%U%)%k%HCM(B
	      $B$O(BBugzilla$B$,%G!<%?$rJ]B8$9$k(BMySQL$B%G!<%?%Y!<%9$NI8=`L>(B
	      \texttt{bugs}$B$G$"$k!%(B

%\item[\rcitem{bugzilla}{notify}] If you want Bugzilla to send out a
%  notification email to subscribers after this hook has added a
%  comment to a bug, you will need this hook to run a command whenever
%  it updates the database.  The command to run depends on where you

%  have installed Bugzilla, but it will typically look something like
%  this, if you have Bugzilla installed in
%  \dirname{/var/www/html/bugzilla}:
%  \begin{codesample4}
%    cd /var/www/html/bugzilla && ./processmail %s [e-mail]
%  \end{codesample4}
%  The Bugzilla \texttt{processmail} program expects to be given a
%  bug~ID (the hook replaces ``\texttt{\%s}'' with the bug~ID) and an
%  email address.  It also expects to be able to write to some files in
%  the directory that it runs in.  If Bugzilla and this hook are not
%  installed on the same machine, you will need to find a way to run
%  \texttt{processmail} on the server where Bugzilla is installed.
\item[\rcitem{bugzilla}{notify}] $B%U%C%/$+$i%P%0$K%3%a%s%H$,DI2C$5$l$?;~!$(B
	      Bugzilla$B$+$i9VFI<T$KDLCN%a!<%k(B
	     $B$,Aw$i$l$k$h$&$K$7$?$$>l9g$O!$%U%C%/$,%G!<%?%Y!<%9$r99?7$7(B
	     $B$?>l9g$O>o$K%3%^%s%I$,<B9T$5$l$k$h$&$K@_Dj$7$J$1$l$P$J$i$J(B
	     $B$$!%<B9T$9$k%3%^%s%I$O!$(BBugzilla$B$r$I$3$K%$%s%9%H!<%k$7$?$+$K(B
	      $B0MB8$9$k!%(BBugzilla$B$r(B\dirname{/var/www/html/bugzilla}$B$K%$%s(B
	     $B%9%H!<%k$7$?>l9g!$E57?E*$J%3%^%s%I$O<!$N$h$&$K$J$k!'(B
  \begin{codesample4}
    cd /var/www/html/bugzilla && ./processmail %s [e-mail]
  \end{codesample4}
Bugzilla \texttt{processmail}$B%W%m%0%i%`$O(Bbug~ID ($B%U%C%/$,(B
``\texttt{\%s}''$B$r(Bbug~ID$B$KCV49$9$k!%(B)$B$H(Bemail$B%"%I%l%9$r<h$k!%$3$N%W%m%0%i(B
$B%`$O$^$?<B9T$5$l$k%G%#%l%/%H%jFb$G$$$/$D$+$N%U%!%$%k$X=q$-9~$_$rI,MW$H$9(B
$B$k!%(BBugzilla$B$H%U%C%/$,F1$8%^%7%s>e$K%$%s%9%H!<%k$5$l$F$$$J$$>l9g!$(B
Bugzilla$B$,%$%s%9%H!<%k$5$l$?%5!<%P>e$G(B\texttt{processmail}$B$r<B9T$9$kJ}K!(B
$B$r8+$D$1$kI,MW$,$"$k!%(B
\end{itemize}

%\subsubsection{Mapping committer names to Bugzilla user names}
\subsubsection{$B%3%_%C%H<T$NL>A0$r(BBugzilla$B$N%f!<%6L>$X%^%C%W$9$k(B}

%By default, the \hgext{bugzilla} hook tries to use the email address
%of a changeset's committer as the Bugzilla user name with which to
%update a bug.  If this does not suit your needs, you can map committer
%email addresses to Bugzilla user names using a \rcsection{usermap}
%section.

$B%G%U%)%k%H$G$O(B\hgext{bugzilla}$B%U%C%/$O%P%0$r99?7$9$k(BBugzilla$B%f!<%6L>$H$7(B
$B$F%A%'%s%8%;%C%H$N%3%_%C%?$N(Bemail$B%"%I%l%9$r;H$*$&$H$9$k!%$3$N5sF0$,K>$^$7(B
$B$/$J$$>l9g$O!$(B\rcsection{usermap}$B%;%/%7%g%s$r@_Dj$9$k$3$H$G%3%_%C%?$N(B
email$B%"%I%l%9$r(BBugzilla$B$N%f!<%6L>$K%^%C%W$9$k$3$H$,$G$-$k!%(B

%Each item in the \rcsection{usermap} section contains an email address
%on the left, and a Bugzilla user name on the right.
%\begin{codesample2}
%  [usermap]
%  [e-mail] = jane
%\end{codesample2}
%You can either keep the \rcsection{usermap} data in a normal \hgrc, or
%tell the \hgext{bugzilla} hook to read the information from an
%external \filename{usermap} file.  In the latter case, you can store
%\filename{usermap} data by itself in (for example) a user-modifiable
%repository.  This makes it possible to let your users maintain their
%own \rcitem{bugzilla}{usermap} entries.  The main \hgrc\ file might
%look like this:
%\begin{codesample2}
%  # regular hgrc file refers to external usermap file
%  [bugzilla]
%  usermap = /home/hg/repos/userdata/bugzilla-usermap.conf
%\end{codesample2}
%While the \filename{usermap} file that it refers to might look like
%this:
%\begin{codesample2}
%  # bugzilla-usermap.conf - inside a hg repository
%  [usermap]
%  [e-mail] = steph
%\end{codesample2}

\rcsection{usermap}$B%;%/%7%g%s$N3F!9$N9`L\$O!$:8JU$K(Bemail$B%"%I%l%9!$1&JU$K(B
Bugzilla$B%f!<%6L>$r;}$D!%(B
\begin{codesample2}
  [usermap]
  [e-mail] = jane
\end{codesample2}
\rcsection{usermap}$B%G!<%?$rDL>o$N(B \hgrc $B%U%!%$%k$KJ]B8$9$k$3$H$b(B
\hgext{bugzilla}$B%U%C%/$K30It$N(B\filename{usermap}$B%U%!%$%k$rFI$`$h$&$K;X<((B
$B$9$k$3$H$b$G$-$k!%8e<T$N>l9g!$Nc$($P(B\filename{usermap}$B%G!<%?$r%f!<%6$,JQ(B
$B992DG=$J%j%]%8%H%j$KCV$/$3$H$b2DG=$G$"$k!%$3$l$O%f!<%6$K(B
\rcitem{bugzilla}{usermap}$B%(%s%H%j$N4IM}$rG$$;$k$3$H$K$J$k!%%a%$%s$N(B
\hgrc\ $B%U%!%$%k$O<!$N$h$&$K$J$k!%!'(B
\begin{codesample2}
  # regular hgrc file refers to external usermap file
  [bugzilla]
  usermap = /home/hg/repos/userdata/bugzilla-usermap.conf
\end{codesample2}

%\subsubsection{Configuring the text that gets added to a bug}
\subsubsection{$B%P%0$KDI2C$5$l$?J8;zNs$r@_Dj$9$k(B}

%You can configure the text that this hook adds as a comment; you
%specify it in the form of a Mercurial template.  Several \hgrc\
%entries (still in the \rcsection{bugzilla} section) control this
%behaviour.
$B%U%C%/$,DI2C$9$k%3%a%s%HJ8;zNs$O(BMercurial$B%F%s%W%l!<%H$H$7$F;XDj$9$k$3$H$,(B
$B$G$-$k!%(B\hgrc $B$N%(%s%H%j(B(\rcsection{bugzilla}$B%;%/%7%g%s$K4^$^$l$F$$$k$b$N(B
$B$r4^$`(B)$B$G5sF0$r%3%s%H%m!<%k$G$-$k!%(B
%\begin{itemize}
%\item[\texttt{strip}] The number of leading path elements to strip
%  from a repository's path name to construct a partial path for a URL.
%  For example, if the repositories on your server live under
%  \dirname{/home/hg/repos}, and you have a repository whose path is
%  \dirname{/home/hg/repos/app/tests}, then setting \texttt{strip} to
%  \texttt{4} will give a partial path of \dirname{app/tests}.  The
%  hook will make this partial path available when expanding a
%  template, as \texttt{webroot}.
%\item[\texttt{template}] The text of the template to use.  In addition
%  to the usual changeset-related variables, this template can use
%  \texttt{hgweb} (the value of the \texttt{hgweb} configuration item
%  above) and \texttt{webroot} (the path constructed using
%  \texttt{strip} above).
%\end{itemize}
\begin{itemize}
\item[\texttt{strip}] URL$B@8@.MQ$NItJ,%Q%9L>$r:n$k$?$a$K%j%]%8%H%j$N%Q%9L>(B
	     $B$+$i<h$j=|$+$l$k@h9TMWAG$N?t!%%5!<%P>e$N(B
	     \dirname{/home/hg/repos}$B$K%j%]%8%H%j72$,$"(B
	     $B$j!$(B\dirname{/home/hg/repos/app/tests}$B$H$$$&%j%]%8%H%j$r;}$C(B
	     $B$F$$$k>l9g!$(B\texttt{strip}$B$r(B\texttt{4}$B$K$9$k$HItJ,%Q%9L>(B
	     \dirname{app/tests}$B$,F@$i$l$k!%%U%C%/$O$3$NItJ,%Q%9$r%F%s%W(B
	     $B%l!<%H$N(B\texttt{webroot}$B$KE,MQ$9$k!%(B

\item[\texttt{template}] $B%F%s%W%l!<%H$K;HMQ$5$l$k%F%-%9%H!%DL>o$N%A%'%s%8(B
	     $B%;%C%H4XO"$NJQ?t$K2C$($F!$(B\texttt{hgweb}$B!J>e5-$N(B
	     \texttt{hgweb}$B$N@_DjCM!K$H(B\texttt{webroot}$B!J>e5-$N(B
	     \texttt{strip}$B$r;H$C$F:n$C$?%Q%9!K$,MxMQ$G$-$k(B.
\end{itemize}

%In addition, you can add a \rcitem{web}{baseurl} item to the
%\rcsection{web} section of your \hgrc.  The \hgext{bugzilla} hook will
%make this available when expanding a template, as the base string to
%use when constructing a URL that will let users browse from a Bugzilla
%comment to view a changeset.  Example:
$B$5$i$K!$(B\rcitem{web}{baseurl}$B9`L\$r(B\hgrc $B$N(B\rcsection{web}$B%;%/%7%g%s$KDI(B
$B2C$G$-$k!%$3$l$O%F%s%W%l!<%H$N3HD%;~$K(B\hgext{bugzilla}$B%U%C%/$K$h$j(B
Bugzilla$B%3%a%s%H$+$i%A%'%s%8%;%C%H$r;2>H$9$k:]$N(BURL$B@8@.$N%Y!<%9J8;zNs$H$7(B
$B$FMxMQ$5$l$k!%(B

\begin{codesample2}
  [web]
  baseurl = http://hg.domain.com/
\end{codesample2}

%Here is an example set of \hgext{bugzilla} hook config information.
\hgext{bugzilla}$B%U%C%/$N@_Dj>pJs$NNc$r<($9!%(B
\begin{codesample2}
  [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.\\nFor complete details, see 
    \{hgweb\}\{webroot\}?cmd=changeset;node=\{node|short\}\\nChangeset
    description:\\n\\t\{desc|tabindent\}
\end{codesample2}

%\subsubsection{Testing and troubleshooting}
\subsubsection{$B%F%9%H$HLdBj2r7h(B}

%The most common problems with configuring the \hgext{bugzilla} hook
%relate to running Bugzilla's \filename{processmail} script and mapping
%committer names to user names.

\hgext{bugzilla}$B%U%C%/$r@_Dj$9$k:]$K(BBugzilla$B$N(B\filename{processmail}$B%9%/(B
$B%j%W%H$N<B9T$H%3%_%C%?!<L>$N%f!<%6L>$X$N%^%C%T%s%0$,$h$/LdBj$K$J$k!%(B

%Recall from section~\ref{sec:hook:bugzilla:config} above that the user
%that runs the Mercurial process on the server is also the one that
%will run the \filename{processmail} script.  The
%\filename{processmail} script sometimes causes Bugzilla to write to
%files in its configuration directory, and Bugzilla's configuration
%files are usually owned by the user that your web server runs under.

\ref{sec:hook:bugzilla:config}$B@a$G!$%5!<%P>e$G(BMercurial$B$rF0:n$5$;$F$$$k%f!<(B
$B%6$H(B\filename{processmail}$B%9%/%j%W%H$rF0$+$7$F$$$k%f!<%6$,F1$8$@$H=R$Y$?!%(B
\filename{processmail}$B%9%/%j%W%H$O(BBugzilla$B$K@_Dj%G%#%l%/%H%jFb$N%U%!%$%k(B
$B$K=q$-9~$^$;$k$3$H$,$"$k!%(B Bugzilla$B$N@_Dj%U%!%$%k$ODL>o!$%&%'%V%5!<%P$r5/(B
$BF0$7$F$$$k%f!<%6$N=jM-$G$"$k!%(B

%You can cause \filename{processmail} to be run with the suitable
%user's identity using the \command{sudo} command.  Here is an example
%entry for a \filename{sudoers} file.
%\begin{codesample2}
%  hg_user = (httpd_user) NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s
%\end{codesample2}
%This allows the \texttt{hg\_user} user to run a
%\filename{processmail-wrapper} program under the identity of
%\texttt{httpd\_user}.

\command{sudo}$B%3%^%s%I$r;H$&$3$H$G(B\filename{processmail}$B$rE,@Z$J%f!<%6$N(B
$B8"8B$G<B9T$9$k$3$H$,$G$-$k!%(B\filename{sudoers}$B%U%!%$%k$N5-=RNc$r<($9!%(B
\begin{codesample2}
  hg_user = (httpd_user) NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s
\end{codesample2}
$B$3$NNc$G$O!$%f!<%6(B\texttt{hg\_user}$B$,(B\filename{processmail-wrapper}$B%W%m%0(B
$B%i%`$r%f!<%6(B\texttt{httpd\_user}$B$N8"8B$N85$G<B9T$9$k$3$H$,$G$-$k!%(B

%This indirection through a wrapper script is necessary, because
%\filename{processmail} expects to be run with its current directory
%set to wherever you installed Bugzilla; you can't specify that kind of
%constraint in a \filename{sudoers} file.  The contents of the wrapper
%script are simple:
%\begin{codesample2}
%  #!/bin/sh
%  cd `dirname $0` && ./processmail "$1" [e-mail]
%\end{codesample2}
%It doesn't seem to matter what email address you pass to
%\filename{processmail}.

$B$3$N%i%C%Q!<%9%/%j%W%H$+$i<B9T$9$k4V@\<B9T$OI,MW$G$"(B
$B$k!%(B\filename{processmail}$B$O(BBugzilla$B$r$I$3$K%$%s%9%H!<%k$7$F$b%+%l%s%H%G%#(B
$B%l%/%H%j$+$i<B9T$5$l$k$?$a$G$"$k!%<B9T@)8B$N<oN`$r(B\filename{sudoers}$B%U%!(B
$B%$%k$K5-=R$9$k!%%i%C%Q!<%9%/%j%W%H$NFbMF$O%7%s%W%k$J$b$N$G$"$k!%(B
\begin{codesample2}
  #!/bin/sh
  cd `dirname $0` && ./processmail "$1" [e-mail]
\end{codesample2}
\filename{processmail}$B$KEO$9(Bemail$B%"%I%l%9$O$I$s$J$b$N$G$b$h$$!%(B

%If your \rcsection{usermap} is not set up correctly, users will see an
%error message from the \hgext{bugzilla} hook when they push changes
%to the server.  The error message will look like this:
%\begin{codesample2}
%  cannot find bugzilla user id for [e-mail]
%\end{codesample2}
%What this means is that the committer's address,
%\texttt{[e-mail]}, is not a valid Bugzilla user name,
%nor does it have an entry in your \rcsection{usermap} that maps it to
%a valid Bugzilla user name.

\rcsection{usermap}$B$,@5$7$/@_Dj$5$l$F$$$J$$>l9g!$JQ99$r%5!<%P$K%W%C%7%e$9(B
$B$k:]$K(B\hgext{bugzilla}$B%U%C%/$+$i$N%(%i!<%a%C%;!<%8$,%f!<%6$KAw$i$l$k!%(B
$B%(%i!<%a%C%;!<%8$O(B
\begin{codesample2}
  cannot find bugzilla user id for [e-mail]
\end{codesample2}
$B$N$h$&$JFbMF$G$"$k!%$3$l$O!$%3%_%C%?$N%"%I%l%9(B
\texttt{[e-mail]}$B$,M-8z$J(BBugzilla$B%f!<%6%M!<%`$G$J$/!$$^(B
$B$?M-8z$J(BBugzilla$B%f!<%6L>$X$N%^%C%W%U%!%$%k$G$"$k(B\rcsection{usermap}$B$K$b(B
$B5-=R$,$J$$$H$$$&0UL#$G$"$k!%(B

%\subsection{\hgext{notify}---send email notifications}
\subsection{\hgext{notify}---$B%a!<%k$GDLCN$r9T$&(B}

%Although Mercurial's built-in web server provides RSS feeds of changes
%in every repository, many people prefer to receive change
%notifications via email.  The \hgext{notify} hook lets you send out
%notifications to a set of email addresses whenever changesets arrive
%that those subscribers are interested in.

Mercurial$B$NAH$_9~$_%&%'%V%5!<%P$OA4$F$N%j%]%8%H%j$NJQ99$N(BRSS$B%U%#!<%I$rDs(B
$B6!$9$k$,!$JQ99$NDLCN$r%a!<%k$G<u$1<h$k$3$H$r9%$`%f!<%6$bB?$$!%(B\hgext{notify}
\hgext{notify}$B%U%C%/$O!$%A%'%s%8%;%C%H$,E~Ce$7$?;~$K4X?4$r;}$D%f!<%6$N%a!<(B
$B%k%"%I%l%9$KDLCN$rAw$k!%(B

%As with the \hgext{bugzilla} hook, the \hgext{notify} hook is
%template-driven, so you can customise the contents of the notification
%messages that it sends.

\hgext{bugzilla}$B$HF1MM$K(B\hgext{notify}$B%U%C%/$b%F%s%W%l!<%H$r;H$C$FAw?.$5(B
$B$l$kDLCN%a%C%;!<%8$NFbMF$r%+%9%?%^%$%:$9$k$3$H$,$G$-$k!%(B

%By default, the \hgext{notify} hook includes a diff of every changeset
%that it sends out; you can limit the size of the diff, or turn this
%feature off entirely.  It is useful for letting subscribers review
%changes immediately, rather than clicking to follow a URL.

$B%G%U%)%k%H$G$O(B\hgext{notify}$B%U%C%/$OAw?.$5$l$kA4$F$N%A%'%s%8%;%C%H$N(Bdiff
$B$r4^$`!%$3$N(Bdiff$B$N%5%$%:$N>e8B$r@_Dj$7$?$j!$Aw?.<+BN$rDd;_$9$k$3$H$,$G$-(B
$B$k!%(Bdiff$B$rAw?.$9$k$H!$9VFI<T$,(BURL$B$r%/%j%C%/$9$k$3$H$J$/JQ99$r$9$0$K%l%S%e!<(B
$B$G$-$kMxE@$,$"$k!%(B

%\subsubsection{Configuring the \hgext{notify} hook}
\subsubsection{\hgext{notify}$B%U%C%/$N@_Dj(B}

%You can set up the \hgext{notify} hook to send one email message per
%incoming changeset, or one per incoming group of changesets (all those
%that arrived in a single pull or push).

\hgext{notify}$B%U%C%/$r@_Dj$7!$E~Ce$7$?%A%'%s%8%;%C%HKh$d!J0lEY$N(Bpull$B$d(B
push$B$GE~Ce$7$?!K0lO"$N%A%'%s%8%;%C%HKh$K(Bemail$B$rAw?.$9$k$3$H$,$G$-(B
$B$k!%(B
\begin{codesample2}
  [hooks]
  # $B0lO"$NJQ99Kh$K%a!<%k$rAw?.$9$k(B
  changegroup.notify = python:hgext.notify.hook
  # $BJQ990l$DKh$K%a!<%k$rAw?.$9$k(B
  incoming.notify = python:hgext.notify.hook
\end{codesample2}

%Configuration information for this hook lives in the
%\rcsection{notify} section of a \hgrc\ file.

$B$3$N%U%C%/$N@_Dj$O(B\hgrc\ $B%U%!%$%k$N(B\rcsection{notify}$B%;%/%7%g%s$K=q$/!%(B
\begin{itemize}
%\item[\rcitem{notify}{test}] By default, this hook does not send out
%  email at all; instead, it prints the message that it \emph{would}
%  send.  Set this item to \texttt{false} to allow email to be sent.
%  The reason that sending of email is turned off by default is that it
%  takes several tries to configure this extension exactly as you would
%  like, and it would be bad form to spam subscribers with a number of
%  ``broken'' notifications while you debug your configuration.
\item[\rcitem{notify}{test}] $B%G%U%)%k%H$G$O$3$N%U%C%/$O%a!<%k$rA4$/Aw?.$7(B
	     $B$J$$!%$=$NBe$o$j!$Aw?.$5$l$N$HF1$8FbMF$rI=<($9$k!%$3$N9`L\$r(B
	     \texttt{false}$B$K@_Dj$9$k$H%a!<%k$,Aw?.$5$l$k!%%G%U%)%k%H$G%a!<(B
	     $B%kAw?.$,%*%U$K$5$l$F$$$kM}M3$O!$0U?^$9$kDL$j$K$3$N@_Dj$r9T$&(B
	     $B$?$a$K$O?t2s$N;n9T$,I,MW$J$?$a$G$"$k!%%G%P%C%0Cf$K9VFI<T$K2u(B
	     $B$l$?DLCN$rAw$k$N$O%9%Q%`$^$,$$$G9%$^$7$/$J$$!%(B

%\item[\rcitem{notify}{config}] The path to a configuration file that
%  contains subscription information.  This is kept separate from the
%  main \hgrc\ so that you can maintain it in a repository of its own.
%  People can then clone that repository, update their subscriptions,
%  and push the changes back to your server.
\item[\rcitem{notify}{config}] $B9VFI<T>pJs$r4^$`@_Dj%U%!%$%k$X$N%Q%9!%%a%$(B
	     $B%s$N(B\hgrc\ $B$HJ,N%$9$k$3$H$G!$%j%]%8%H%jKh$K%j%]%8%H%jFb$G4I(B
	     $BM}$G$-$k!%6(NO<T$O%j%]%8%H%j$r%/%m!<%s$7!$9VFI<T$r%"%C%W%G!<(B
	     $B%H$7$FJQ99$r%5!<%P$K(Bpush$B$G$-$k!%(B

%\item[\rcitem{notify}{strip}] The number of leading path separator
%  characters to strip from a repository's path, when deciding whether
%  a repository has subscribers.  For example, if the repositories on
%  your server live in \dirname{/home/hg/repos}, and \hgext{notify} is
%  considering a repository named \dirname{/home/hg/repos/shared/test},
%  setting \rcitem{notify}{strip} to \texttt{4} will cause
%  \hgext{notify} to trim the path it considers down to
%  \dirname{shared/test}, and it will match subscribers against that.
\item[\rcitem{notify}{strip}] $B%j%]%8%H%j$K9VFI<T$,$$$k$+$I$&$+H=Dj$9$k:](B
	     $B$K!$%j%]%8%H%j$N%Q%9$+$i=|5n$9$k@h9TItJ,$r%Q%96h@Z$jJ8;z$G<((B
	     $B$7$??t!%Nc$($P!$%5!<%P$G%j%]%8%H%j72$,(B
	     \dirname{/home/hg/repos}$B$KCV$+$l$F$*$j!$(B \hgext{notify}$B$,(B
	     \dirname{/home/hg/repos/shared/test}$B$H$$$&%j%]%8%H%j$rBP>]$H(B
	     $B$9$k;~!$(B\rcitem{notify}{strip} $B$r(B \texttt{4}$B$K@_Dj$9$k$H(B
	     \hgext{notify}$B$O%Q%9$r(B\dirname{shared/test}$B$KC;=L$7!$$3$l$r(B
	     $BMQ$$$F9VFI<T$N%^%C%A$r9T$&!%(B

%\item[\rcitem{notify}{template}] The template text to use when sending
%  messages.  This specifies both the contents of the message header
%  and its body.
\item[\rcitem{notify}{template}] $B%a%C%;!<%8$rAw?.$9$k;~$K;H$o$l$k%F%-%9(B
	     $B%H$N%F%s%W%l!<%H!%%a%C%;!<%8$N%X%C%@$H%\%G%#N>J}$r@_Dj$9$k(B
	     $B$3$H$,$G$-$k!%(B

%\item[\rcitem{notify}{maxdiff}] The maximum number of lines of diff
%  data to append to the end of a message.  If a diff is longer than
%  this, it is truncated.  By default, this is set to 300.  Set this to
%  \texttt{0} to omit diffs from notification emails.
\item[\rcitem{notify}{maxdiff}] $B%a%C%;!<%8$NKvHx$KE:IU$5$l$k(Bdiff$B%G!<%?$N(B
	     $B:GBg9T?t!%(Bdiff$B$,$3$NCM$h$jBg$-$$>l9g$O@Z$j5M$a$i$l$k!%%G%U%)(B
	     $B%k%H$G$O(B300$B9T!%$3$NCM$r(B\texttt{0}$B$K$9$k$3$H$GDLCN(Bemail$B$X$N(B
	     diff$B$NE:IU$rM^@)$9$k$3$H$,$G$-$k!%(B

%\item[\rcitem{notify}{sources}] A list of sources of changesets to
%  consider.  This lets you limit \hgext{notify} to only sending out
%  email about changes that remote users pushed into this repository
%  via a server, for example.  See section~\ref{sec:hook:sources} for
%  the sources you can specify here.
\item[\rcitem{notify}{sources}] $BBP>]%A%'%s%8%;%C%H$N%=!<%9$N%j%9%H!%Nc$((B
	     $B$P!$$3$N%j%9%H$G%j%b!<%H%f!<%6$,%5!<%P7PM3$G%j%]%8%H%j$X%W%C(B
	     $B%7%e$7$?JQ99$K4X$7$F$N$_DLCN$r9T$&$h$&$K@)8B$9$k$3$H$,$G$-(B
	     $B$k!%$3$3$G;XDj$G$-$k%=!<%9$K$D$$$F$O(B\ref{sec:hook:sources}
	     $B@a$r;2>H$N$3$H!%(B
\end{itemize}

%If you set the \rcitem{web}{baseurl} item in the \rcsection{web}
%section, you can use it in a template; it will be available as
%\texttt{webroot}.

\rcsection{web}$B%;%/%7%g%s$N(B\rcitem{web}{baseurl}$B9`L\$r@_Dj$7$F$$$k$J$i!$(B
$B$3$l$r(B\texttt{webroot}$B$H$7$F%F%s%W%l!<%HFb$G;H$&$3$H$,$G$-$k!%(B

%Here is an example set of \hgext{notify} configuration information.
\hgext{notify}$B@_Dj$NNc$r<($9!%(B
%\begin{codesample2}
%  [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\}
%    Subject: \{webroot\}: \{desc|firstline|strip\}
%    From: \{author\}
%
%    changeset \{node|short\} in \{root\}
%    details: \{baseurl\}\{webroot\}?cmd=changeset;node=\{node|short\}
%    description:
%      \{desc|tabindent|strip\}
%
%  [web]
%  baseurl = http://hg.example.com/
%\end{codesample2}

\begin{codesample2}
  [notify]
  # $B<B:]$K%a!<%k$rAw?.$9$k$+(B
  test = false
  # $B9VFI<T%G!<%?$,DLCN%j%]%8%H%jFb$K$"$k(B
  config = /home/hg/repos/notify/notify.conf
  # $B%j%]%8%H%j72$O%5!<%P$N(B /home/hg/repos $B$K$"$k$N$G(B 4$B$D$N(B "/" $BJ8;z$r%9%H%j%C%W$9$k(B
  strip = 4
  template = X-Hg-Repo: \{webroot\}
    Subject: \{webroot\}: \{desc|firstline|strip\}
    From: \{author\}

    changeset \{node|short\} in \{root\}
    details: \{baseurl\}\{webroot\}?cmd=changeset;node=\{node|short\}
    description:
      \{desc|tabindent|strip\}

  [web]
  baseurl = http://hg.example.com/
\end{codesample2}

%This will produce a message that looks like the following:
$B@8@.$5$l$k%a%C%;!<%8$O<!$N$h$&$K$J$k!'(B
\begin{codesample2}
  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...]
\end{codesample2}

%\subsubsection{Testing and troubleshooting}
\subsubsection{$B%F%9%H$HLdBj2r7h(B}

%Do not forget that by default, the \hgext{notify} extension \emph{will
%  not send any mail} until you explicitly configure it to do so, by
%setting \rcitem{notify}{test} to \texttt{false}.  Until you do that,
%it simply prints the message it \emph{would} send.

$B%G%U%)%k%H$G$O(B\hgext{notify}$B%(%/%9%F%s%7%g%s$O(B\emph{$B%a!<%k$rAw?.$7$J$$(B}$B$3(B
$B$H$KN10U$9$k$3$H!%<B:]$KAw?.$5$;$k$?$a$K$OL@<(E*$K(B\rcitem{notify}{test}$B$r(B
\texttt{false}$B$K@_Dj$7$J$1$l$P$J$i$J$$!%$3$N@_Dj$r$7$J$1$l$P!$Aw?.$9$k$N(B
$B$HF1$8%a%C%;!<%8$rI=<($9$k$@$1$G$"$k!%(B

%\section{Information for writers of hooks}
\section{$B%U%C%/:n@=<T$X$N>pJs(B}
\label{sec:hook:ref}

%\subsection{In-process hook execution}
\subsection{$B%W%m%;%9Fb%U%C%/$N<B9T(B}

%An in-process hook is called with arguments of the following form:
$B%W%m%;%9Fb%U%C%/$O<!$N$h$&$J7A<0$N0z?t$rH<$C$F8F$S=P$5$l$k!'(B
\begin{codesample2}
  def myhook(ui, repo, **kwargs):
      pass
\end{codesample2}
%The \texttt{ui} parameter is a \pymodclass{mercurial.ui}{ui} object.
%The \texttt{repo} parameter is a
%\pymodclass{mercurial.localrepo}{localrepository} object.  The
%names and values of the \texttt{**kwargs} parameters depend on the
%hook being invoked, with the following common features:
\texttt{ui}$B%Q%i%a!<%?$O(B\pymodclass{mercurial.ui}{ui}$B$N%*%V%8%'%/%H$G$"$k!%(B
\texttt{repo}$B%Q%i%a!<%?$O(B
\pymodclass{mercurial.localrepo}{localrepository}$B$N%*%V%8%'%/%H$G$"$k!%(B
\texttt{**kwargs}$B%Q%i%a!<%?$NL>A0$HCM$O!$8F$S=P$5$l$k%U%C%/$K0MB8$7!$<!(B
$B$N$h$&$J6&DL$7$?FCD'$r;}$D!%(B
%\begin{itemize}
%\item If a parameter is named \texttt{node} or
%  \texttt{parent\emph{N}}, it will contain a hexadecimal changeset ID.
%  The empty string is used to represent ``null changeset ID'' instead
%  of a string of zeroes.
%\item If a parameter is named \texttt{url}, it will contain the URL of
%  a remote repository, if that can be determined.
%\item Boolean-valued parameters are represented as Python
%  \texttt{bool} objects.
%\end{itemize}
\begin{itemize}
\item $B%Q%i%a!<%?$,(B\texttt{node}$B$^$?$O(B\texttt{parent\emph{N}}$B$HL>IU$1$i$l(B
      $B$?>l9g!$(B16$B?J?t$N%A%'%s%8%;%C%H(BID$B$r;}$D!%(B ``$B%L%k%A%'%s%8%;%C%H(BID''$B$r(B
      $BI=$9$?$a$K(B0$B$G$O$J$/6u$NJ8;zNs$,MQ$$$i$l$k!%(B
\item $B%Q%i%a!<%?$,(B\texttt{url}$B$HL>IU$1$i$l$?>l9g!$%j%b!<%H%j%]%8%H%j$,FC(B
      $BDj$5$l$k$J$i$P$=$N(BURL$B$r;}$D!%(B
\item $B%V!<%kCM$r;}$D%Q%i%a!<%?$O(BPython$B$N(B\texttt{bool}$B%*%V%8%'%/%H$H$7$F(B
      $BI=8=$5$l$k!%(B
\end{itemize}

%An in-process hook is called without a change to the process's working
%directory (unlike external hooks, which are run in the root of the
%repository).  It must not change the process's working directory, or
%it will cause any calls it makes into the Mercurial API to fail.

$B%W%m%;%9Fb%U%C%/$O!$%j%]%8%H%j$N%k!<%H$G<B9T$5$l$k30It%U%C%/$H0[$J$j%W%m(B
$B%;%9$N%o!<%-%s%0%G%#%l%/%H%j$NJQ99$J$7$K8F$S=P$5$l$k!%%W%m%;%9Fb%U%C%/$O(B
$B%W%m%;%9%o!<%-%s%0%G%#%l%/%H%j$rJQ99$7$F$O$J$i$J$$!%$5$b$J$1$l(B
$B$P!$(BMercurial API$B$X$N8F$S=P$7$OA4$F<:GT$9$k!%(B

%If a hook returns a boolean ``false'' value, it is considered to have
%succeeded.  If it returns a boolean ``true'' value or raises an
%exception, it is considered to have failed.  A useful way to think of
%the calling convention is ``tell me if you fail''.

$B%U%C%/$,%V!<%kCM(B``false''$B$rJV$7$?>l9g!$%U%C%/$N<B9T$O@.8y$7$?$H8+$J$5$l(B
$B$k!%%V!<%kCM(B``true''$B$rJV$7$?>l9g$*$h$SNc30$rH/@8$5$;$?>l9g$O<:GT$7$?$H8+(B
$B$J$5$l$k!%8F$S=P$74{Ls$O(B ``$B<:GT$7$?;~$O65$($k(B''$B$H3P$($k$H$h$$!%(B

%Note that changeset IDs are passed into Python hooks as hexadecimal
%strings, not the binary hashes that Mercurial's APIs normally use.  To
%convert a hash from hex to binary, use the
%\pymodfunc{mercurial.node}{bin} function.

Python$B%U%C%/$KEO$5$l$k%A%'%s%8%;%C%H(BID$B$O!$(BMercurial API$B$,DL>oMQ$$$k%P%$%J(B
$B%j%O%C%7%eCM$G$O$J$/(B16$B?J?tJ8;zNs$G$"$k$3$H$KCm0U!%%O%C%7%eCM$r(B16$B?J?tJ8;z(B
$BNs$+$i%P%$%J%j$KJQ49$9$k$K$O(B\pymodfunc{mercurial.node}{bin}$B4X?t$rMQ$$$k!%(B

%\subsection{External hook execution}
\subsection{$B%U%C%/$N30It<B9T(B}

%An external hook is passed to the shell of the user running Mercurial.
%Features of that shell, such as variable substitution and command
%redirection, are available.  The hook is run in the root directory of
%the repository (unlike in-process hooks, which are run in the same
%directory that Mercurial was run in).

$B30It%U%C%/$O(BMercurial$B$r<B9T$7$F$$$k%7%'%k$G<B9T$5$l$k!%JQ?t$NCV49$d%3%^%s(B
$B%I$N%j%@%$%l%/%H$J$I$N%7%'%k$N5!G=$,MxMQ$G$-$k!%30It%U%C%/$O!$(BMercurial$B$N(B
$B<B9T$HF1$8%G%#%l%/%H%jFb$G<B9T$5$l$k%W%m%;%9Fb%U%C%/$H$O0[$J$j!$%j%]%8%H(B
$B%j$N%k!<%H%G%#%l%/%H%j$G<B9T$5$l$k!%(B

%Hook parameters are passed to the hook as environment variables.  Each
%environment variable's name is converted in upper case and prefixed
%with the string ``\texttt{HG\_}''.  For example, if the name of a
%parameter is ``\texttt{node}'', the name of the environment variable
%representing that parameter will be ``\texttt{HG\_NODE}''.

$B%U%C%/%Q%i%a!<%?$O%U%C%/$K4D6-JQ?t$H$7$FEO$5$l$k!%3F!9$N4D6-JQ?tL>$OBgJ8(B
$B;z$KJQ49$5$l!$@\F,<-(B``\texttt{HG\_}''$B$,IU$1$i$l$k!%Nc$($P(B
``\texttt{node}''$B$H$$$&%Q%i%a!<%?$,;H$o$l$?$H$9$k$H!$$3$N%Q%i%a!<%?$rI=(B
$B$94D6-JQ?tL>$O(B``\texttt{HG\_NODE}''$B$H$J$k!%(B

%A boolean parameter is represented as the string ``\texttt{1}'' for
%``true'', ``\texttt{0}'' for ``false''.  If an environment variable is
%named \envar{HG\_NODE}, \envar{HG\_PARENT1} or \envar{HG\_PARENT2}, it
%contains a changeset ID represented as a hexadecimal string.  The
%empty string is used to represent ``null changeset ID'' instead of a
%string of zeroes.  If an environment variable is named
%\envar{HG\_URL}, it will contain the URL of a remote repository, if
%that can be determined.

$B%V!<%kCM%Q%i%a!<%?$K$D$$$F$O!$??$,(B``\texttt{1}''$B!$56$,(B``\texttt{0}''$B$HI=(B
$B8=$5$l$k!%(B\envar{HG\_NODE}$B!$(B\envar{HG\_PARENT1}$B!$(B\envar{HG\_PARENT2}$B$H$$(B
$B$&4D6-JQ?t$,Dj5A$5$l$F$$$k$H$-!$$3$l$i$O(B16$B?J?t$NJ8;zNs$GI=$5$l$?%A%'%s%8(B
$B%;%C%H(BID$B$r4^$`!%(B``$B%L%k%A%'%s%8%;%C%H(BID''$B$rI=8=$9$k$?$a$K%<%m$G$J$/6u$NJ8(B
$B;zNs$,MQ$$$i$l$k!%4D6-JQ?t$,(B\envar{HG\_URL}$B$G$"$k$H$-!$%j%b!<%H%j%]%8%H%j(B
$B$,FCDj$G$-$l$P!$$=$N(BURL$B$,F~$k!%(B

%If a hook exits with a status of zero, it is considered to have
%succeeded.  If it exits with a non-zero status, it is considered to
%have failed.

$B%U%C%/$,%9%F!<%?%9(B0$B$G=*N;$7$?>l9g$O@.8y$H8+$J$5$l$k!%(B0$B0J30$N%9%F!<%?%9$G(B
$B=*N;$7$?>l9g$O<B9T$,<:GT$7$?$H8+$J$5$l$k!%(B

%\subsection{Finding out where changesets come from}
\subsection{$B%A%'%s%8%;%C%H$N%=!<%9$rD4$Y$k(B}

%A hook that involves the transfer of changesets between a local
%repository and another may be able to find out information about the
%``far side''.  Mercurial knows \emph{how} changes are being
%transferred, and in many cases \emph{where} they are being transferred
%to or from.

$B%m!<%+%k$J%j%]%8%H%j!&B>$N%j%]%8%H%j4V$N%A%'%s%8%;%C%H$NE>Aw$K4XO"$7$?%U%C(B
$B%/$O!$1s3VCO$N>pJs$rF@$k$3$H$,$G$-$k!%(BMercurial$B$O(B\emph{$B$I$N$h$&$K(B}$BJQ99$,(B
$BE>Aw$5$l$k$+!$$^$?B?$/$N>l9g(B\emph{$B$I$3$X(B}$B!$$"$k$$$O(B\emph{$B$I$3$+$i(B}$BE>Aw$5(B
$B$l$k$N$+$bCN$k$3$H$,$G$-$k!%(B

%\subsubsection{Sources of changesets}
\subsubsection{$B%A%'%s%8%;%C%H$N%=!<%9(B}
\label{sec:hook:sources}

%Mercurial will tell a hook what means are, or were, used to transfer
%changesets between repositories.  This is provided by Mercurial in a
%Python parameter named \texttt{source}, or an environment variable named
%\envar{HG\_SOURCE}.

Mercurial$B$O%U%C%/$K%A%'%s%8%;%C%H$NFbMF!$%j%]%8%H%j4V$NE>AwJ}K!$J$I$rDLCN(B
$B$9$k!%(B Mercurial$B$ODLCN$N$?$a$K(B\texttt{source}$B$H$$$&(BPython$B%Q%i%a!<%?$^$?$O(B
\envar{HG\_SOURCE}$B$H$$$&4D6-JQ?t$rMQ$$$k!%(B

%\begin{itemize}
%\item[\texttt{serve}] Changesets are transferred to or from a remote
%  repository over http or ssh.
%\item[\texttt{pull}] Changesets are being transferred via a pull from
%  one repository into another.
%\item[\texttt{push}] Changesets are being transferred via a push from
%  one repository into another.
%\item[\texttt{bundle}] Changesets are being transferred to or from a
%  bundle.
%\end{itemize}

\begin{itemize}
\item[\texttt{serve}] $B%A%'%s%8%;%C%H$O%j%b!<%H%j%]%8%H%j$+$i(Bhttp$B$^$?$O(B
	     ssh$B$GE>Aw$5$l$?!%(B
\item[\texttt{pull}] $B%A%'%s%8%;%C%H$O(B2$B$D$N%j%]%8%H%j4V$r(Bpull$B$K$h$C$FE>Aw(B
	     $B$5$l$?!%(B
\item[\texttt{push}] $B%A%'%s%8%;%C%H$O(B2$B$D$N%j%]%8%H%j4V$r(Bpush$B$K$h$C$FE>Aw(B
	     $B$5$l$?!%(B
\item[\texttt{bundle}] $B%A%'%s%8%;%C%H$O%P%s%I%k$K$h$C$FE>Aw$5$l$?!%(B
\end{itemize}

%\subsubsection{Where changes are going---remote repository URLs}
\subsubsection{$BJQ99$N9T$-@h(B---$B%j%b!<%H%j%]%8%H%j$N(BURL}
\label{sec:hook:url}

%When possible, Mercurial will tell a hook the location of the ``far
%side'' of an activity that transfers changeset data between
%repositories.  This is provided by Mercurial in a Python parameter
%named \texttt{url}, or an environment variable named \envar{HG\_URL}.

Mercurial$B$O!$2DG=$G$"$k$J$i$P%j%]%8%H%j4V$N%A%'%s%8%;%C%H%G!<%?$NE>Aw$NAj(B
$B<j$N>pJs$r%U%C%/$KDLCN$9$k!%(B Mercurial$B$O(B\texttt{url}$B$H$$$&(BPython$B%Q%i%a!<(B
$B%?$^$?$O(B\envar{HG\_URL}$B$H$$$&4D6-JQ?t$r;H$C$FDLCN$r9T$&!%(B

%This information is not always known.  If a hook is invoked in a
%repository that is being served via http or ssh, Mercurial cannot tell
%where the remote repository is, but it may know where the client is

%connecting from.  In such cases, the URL will take one of the
%following forms:
%\begin{itemize}
%\item \texttt{remote:ssh:\emph{ip-address}}---remote ssh client, at
%  the given IP address.
%\item \texttt{remote:http:\emph{ip-address}}---remote http client, at
%  the given IP address.  If the client is using SSL, this will be of
%  the form \texttt{remote:https:\emph{ip-address}}.
%\item Empty---no information could be discovered about the remote
%  client.
%\end{itemize}

$B$3$N>pJs$O$$$D$b4{CN$G$"$k!%(Bhttp$B$^$?$O(Bssh$B$G%5!<%S%9$5$l$F$$$k%j%]%8%H%j$+(B
$B$i%U%C%/$,5/F0$5$l$?>l9g!$(BMercurial$B$O%j%b!<%H%j%]%8%H%j$,$I$3$K$"$k$N$+$r(B
$BDLCN$9$k$3$H$O$G$-$J$$$,!$%/%i%$%"%s%H$,$I$3$+$i@\B3$7$F$$$k$N$+$OCN$k$3(B
$B$H$,$G$-$k!%(B

$B$=$N>l9g!$(BURL$B$O<!$N$$$:$l$+$N7A<0$r<h$k!'(B
\begin{itemize}
\item \texttt{remote:ssh:\emph{ip-address}}---$B$"$k(BIP$B%"%I%l%9>e$N%j%b!<%H(B
      ssh$B%/%i%$%"%s%H(B
\item \texttt{remote:http:\emph{ip-address}}---$B$"$k(BIP$B%"%I%l%9>e$N(Bhttp$B%/(B
      $B%i%$%"%s%H!%$b$7%/%i%$%"%s%H$,(BSSL$B$r;HMQ$7$F$$$k>l(B
      $B9g!$(B\texttt{remote:https:\emph{ip-address}}$B$N$h$&$J7A<0$K$J$k!%(B
\item Empty---$B%j%b!<%H%/%i%$%"%s%H$K4X$9$k>pJs$,$J$$!%(B
\end{itemize}

%\begin{itemize}
%\item \texttt{remote:ssh:\emph{ip-address}}---remote ssh client, at
%  the given IP address.
%\item \texttt{remote:http:\emph{ip-address}}---remote http client, at
%  the given IP address.  If the client is using SSL, this will be of
%  the form \texttt{remote:https:\emph{ip-address}}.
%\item Empty---no information could be discovered about the remote
%  client.
%\end{itemize}

\begin{itemize}
\item \texttt{remote:ssh:\emph{ip-address}}---$BM?$($i$l$?(BIP$B%"%I%l%9$N%j%b!<(B
      $B%H(Bssh$B%/%i%$%"%s%H!%(B
\item \texttt{remote:http:\emph{ip-address}}---$BM?$($i$l$?(BIP$B%"%I%l%9$N%j%b!<(B
      $B%H(Bhttp$B%/%i%$%"%s%H!%%/%i%$%"%s%H$,(BSSL$B$r;H$C$F$$$k>l9g$O(B
      \texttt{remote:https:\emph{ip-address}}$B$N7A<0$K$J$k!%(B
\item $B6uGr(B---$B%j%b!<%H%/%i%$%"%s%H$K$D$$$F$N>pJs$OF@$i$l$J$+$C$?!%(B
\end{itemize}

%\section{Hook reference}
\section{$B%U%C%/;2>H(B}

%\subsection{\hook{changegroup}---after remote changesets added}
\subsection{\hook{changegroup}---$B%j%b!<%H%A%'%s%8%;%C%H$,DI2C$5$l$?8e(B}
\label{sec:hook:changegroup}

%This hook is run after a group of pre-existing changesets has been
%added to the repository, for example via a \hgcmd{pull} or
%\hgcmd{unbundle}.  This hook is run once per operation that added one
%or more changesets.  This is in contrast to the \hook{incoming} hook,
%which is run once per changeset, regardless of whether the changesets
%arrive in a group.

$B$3$N%U%C%/$O!$(B\hgcmd{pull}$B$^$?$O(B\hgcmd{unbundle}$B$J$I$G4{B8$N%A%'%s%8%;%C(B
$B%H%0%k!<%W$,%j%]%8%H%j$KDI2C$5$l$?8e$K<B9T$5$l$k!%$3$N%U%C%/$O!$(B1$B$D0J>e$N(B
$B%A%'%s%8%;%C%H$rDI2C$9$k%*%Z%l!<%7%g%s$K$D$-0lEY<B9T$5$l$k!%%0%k!<%W$K4X(B
$B78$J$/%A%'%s%8%;%C%H(B1$B$DKh$K<B9T$5$l$k(B\hook{incoming}$B%U%C%/$H$OBP>HE*$G$"(B
$B$k!%(B

%Some possible uses for this hook include kicking off an automated
%build or test of the added changesets, updating a bug database, or
%notifying subscribers that a repository contains new changes.

$B$3$N%U%C%/$r;H$C$FDI2C$5$l$?%A%'%s%8%;%C%H$KBP$9$k<+F0%S%k%I$d%F%9%H$r5/(B
$BF0$9$k$3$H$d!$?7$?$JJQ99$r;}$D%j%]%8%H%j$N9VFI<T$KDLCN$9$k$3$H$,$G$-$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{node}] A changeset ID.  The changeset ID of the first
%  changeset in the group that was added.  All changesets between this
%  and \index{tags!\texttt{tip}}\texttt{tip}, inclusive, were added by
%  a single \hgcmd{pull}, \hgcmd{push} or \hgcmd{unbundle}.
%\item[\texttt{source}] A string.  The source of these changes.  See
%  section~\ref{sec:hook:sources} for details.
%\item[\texttt{url}] A URL.  The location of the remote repository, if
%  known.  See section~\ref{sec:hook:url} for more information.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%DI2C$5$l$?%0%k!<%W$N:G=i$N%A%'%s%8(B
	     $B%;%C%H$N(BID$B!%$3$N(BID$B$r4^$_(B
	     \index{tags!\texttt{tip}}\texttt{tip}$B$^$G$N4V$N%A%'%s%8%;%C(B
	     $B%HA4$F$O0l2s$N(B\hgcmd{pull}$B!$(B\hgcmd{push}$B$^$?$O(B
	     \hgcmd{unbundle}$B$GDI2C$5$l$?!%(B
\item[\texttt{source}] $BJ8;zNs!%$3$l$i$NJQ99$N%=!<%9!%>\:Y$K$D$$$F$O(B
	     \ref{sec:hook:sources}$B$r;2>H$N$3$H!%(B
\item[\texttt{url}] URL$B!%%j%b!<%H%j%]%8%H%j$,FCDj$G$-$k>l9g$O$=$N%"%I%l(B
	     $B%9!%>\:Y$K$D$$$F$O(B\ref{sec:hook:url}$B$r;2>H$N$3$H!%(B
\end{itemize}

%See also: \hook{incoming} (section~\ref{sec:hook:incoming}),
%\hook{prechangegroup} (section~\ref{sec:hook:prechangegroup}),
%\hook{pretxnchangegroup} (section~\ref{sec:hook:pretxnchangegroup})

$B;29M!'(B\hook{incoming} (\ref{sec:hook:incoming}$B@a(B), \hook{prechangegroup}
(\ref{sec:hook:prechangegroup}$B@a(B), \hook{pretxnchangegroup}
(\ref{sec:hook:pretxnchangegroup}$B@a(B)

%\subsection{\hook{commit}---after a new changeset is created}
\subsection{\hook{commit}---$B?7$7$$%A%'%s%8%;%C%H$,:n@.$5$l$?8e(B}
\label{sec:hook:commit}

%This hook is run after a new changeset has been created.

$B$3$N%U%C%/$O?7$?$J%A%'%s%8%;%C%H$,:n$i$l$?8e$K8F$P$l$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{node}] A changeset ID.  The changeset ID of the newly
%  committed changeset.
%\item[\texttt{parent1}] A changeset ID.  The changeset ID of the first
%  parent of the newly committed changeset.
%\item[\texttt{parent2}] A changeset ID.  The changeset ID of the second
%  parent of the newly committed changeset.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$K%3%_%C%H$5$l$?%A%'%s%8%;%C(B
	     $B%H$N(BID$B!%(B
\item[\texttt{parent1}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$K%3%_%C%H$5$l$?%A%'%s%8%;%C(B
	     $B%H$N(B1$B$DL\$N?F$N%A%'%s%8%;%C%H(BID.
\item[\texttt{parent2}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$K%3%_%C%H$5$l$?%A%'%s%8%;%C(B
	     $B%H$N(B2$B$DL\$N?F$N%A%'%s%8%;%C%H(BID.
\end{itemize}

%See also: \hook{precommit} (section~\ref{sec:hook:precommit}),
%\hook{pretxncommit} (section~\ref{sec:hook:pretxncommit})

$B;29M!'(B\hook{precommit} (\ref{sec:hook:precommit}$B@a(B), \hook{pretxncommit}
(\ref{sec:hook:pretxncommit}$B@a(B)


%\subsection{\hook{incoming}---after one remote changeset is added}
\subsection{\hook{incoming}---$B%j%b!<%H%A%'%s%8%;%C%H$,DI2C$5$l$?8e(B}
\label{sec:hook:incoming}

%This hook is run after a pre-existing changeset has been added to the
%repository, for example via a \hgcmd{push}.  If a group of changesets
%was added in a single operation, this hook is called once for each
%added changeset.

$B$3$N%U%C%/$O(B\hgcmd{push}$B%3%^%s%I$J$I$G4{B8$N%A%'%s%8%;%C%H$,%j%]%8%H%j$K(B
$BDI2C$5$l$?8e$G<B9T$5$l$k!%%A%'%s%8%;%C%H$N%0%k!<%W$,0lEY$KDI2C$5$l$?>l(B
$B9g!$3F!9$N%A%'%s%8%;%C%H$K$D$$$F0lEY$:$D$3$N%U%C%/$,8F$S=P$5$l$k!%(B

%You can use this hook for the same purposes as the \hook{changegroup}
%hook (section~\ref{sec:hook:changegroup}); it's simply more convenient
%sometimes to run a hook once per group of changesets, while other
%times it's handier once per changeset.

$B$3$N%U%C%/$O(B\hook{changegroup}(\ref{sec:hook:changegroup}$B@a(B)$B$HF1$8L\E*$G(B
$B;H$&$3$H$,$G$-$k!%0c$$$O(B\hook{changegroup}$B$,%A%'%s%8%;%C%H%0%k!<%WA4BN$K(B
$BBP$7$F0lEY8F$P$l$kE@$G$"$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{node}] A changeset ID.  The ID of the newly added
%  changeset.
%\item[\texttt{source}] A string.  The source of these changes.  See
%  section~\ref{sec:hook:sources} for details.
%\item[\texttt{url}] A URL.  The location of the remote repository, if
%  known.  See section~\ref{sec:hook:url} for more information.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$KDI2C$5$l$k%A%'%s%8%;%C%H$N(B
	     ID$B!%(B
\item[\texttt{source}] $BJ8;zNs!%$3$l$i$NJQ99$N%=!<%9!%>\:Y$K$D$$$F$O(B
	     \ref{sec:hook:sources}$B$r;2>H$N$3$H!%(B
\item[\texttt{url}] URL$B!%%j%b!<%H%j%]%8%H%j$,FCDj$G$-$k>l9g$K$O$=$N%"%I(B
	     $B%l%9!%>\:Y$K$D$$$F$O(B\ref{sec:hook:url}$B$r;2>H$N$3$H!%(B
\end{itemize}

%See also: \hook{changegroup} (section~\ref{sec:hook:changegroup}) \hook{prechangegroup} (section~\ref{sec:hook:prechangegroup}), \hook{pretxnchangegroup} (section~\ref{sec:hook:pretxnchangegroup})
$B;29M!'(B\hook{changegroup} (\ref{sec:hook:changegroup}$B@a(B)
\hook{prechangegroup} (\ref{sec:hook:prechangegroup}$B@a(B),
\hook{pretxnchangegroup} (\ref{sec:hook:pretxnchangegroup}$B@a(B)

%\subsection{\hook{outgoing}---after changesets are propagated}
\subsection{\hook{outgoing}---$B%A%'%s%8%;%C%H$,GH5Z$7$?8e(B}
\label{sec:hook:outgoing}

%This hook is run after a group of changesets has been propagated out
%of this repository, for example by a \hgcmd{push} or \hgcmd{bundle}
%command.

$B$3$N%U%C%/$O%A%'%s%8%;%C%H$N%0%k!<%W$,(B\hgcmd{push}$B$d(B\hgcmd{bundle}$B%3%^%s(B
$B%I$J$I$K$h$C$F30It$KGH5Z$7$?8e$G<B9T$5$l$k!%(B

%One possible use for this hook is to notify administrators that
%changes have been pulled.

$B$3$N%U%C%/$r;H$C$F4IM}<T$O(Bpull$B$5$l$?JQ99$rCN$k$3$H$,$G$-$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{node}] A changeset ID.  The changeset ID of the first
%  changeset of the group that was sent.
%\item[\texttt{source}] A string.  The source of the of the operation
%  (see section~\ref{sec:hook:sources}).  If a remote client pulled
%  changes from this repository, \texttt{source} will be
%  \texttt{serve}.  If the client that obtained changes from this
%  repository was local, \texttt{source} will be \texttt{bundle},
%  \texttt{pull}, or \texttt{push}, depending on the operation the
%  client performed.
%\item[\texttt{url}] A URL.  The location of the remote repository, if
%  known.  See section~\ref{sec:hook:url} for more information.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%Aw?.$5$l$?%A%'%s%8%;%C%H%0%k!<%W(B
	     $B$N:G=i$N%A%'%s%8%;%C%H(BID.
\item[\texttt{source}] $BJ8;zNs!%A`:n85(B(~\ref{sec:hook:sources}$B@a$r;2>H(B)$B!%(B
	     $B%j%b!<%H%/%i%$%"%s%H$,JQ99$r%j%]%8%H%j$+$i(Bpull$B$9$k$H(B
	     \texttt{source}$B$,(B\texttt{serve}$B$H$J$k!%%j%]%8%H%j$+$iJQ99$r(B
	     $BF~<j$7$?%/%i%$%"%s%H$,%m!<%+%k$G$"$l$P!$(B\texttt{source}$B$O%/(B
	     $B%i%$%"%s%H$N9T$C$?F0:n$K1~$8$F(B
	     \texttt{bundle}$B!$(B\texttt{pull}$B!$(B\texttt{push}$B$N$$$:$l$+$H$J(B
	     $B$k!%(B
\item[\texttt{url}] URL$B!%%j%b!<%H%j%]%8%H%j$,FCDj$G$-$k>l9g$O$=$N%"%I%l%9!%(B
	     $B>\:Y$K$D$$$F$O(B\ref{sec:hook:url}$B@a$r;2>H$N$3$H!%(B
\end{itemize}


%See also: \hook{preoutgoing} (section~\ref{sec:hook:preoutgoing})
$B;29M!'(B \hook{preoutgoing} (\ref{sec:hook:preoutgoing}$B@a(B)

%\subsection{\hook{prechangegroup}---before starting to add remote
%changesets}
\subsection{\hook{prechangegroup}---$B%j%b!<%H%A%'%s%8%;%C%H$,$,DI2C$5$l$k(B
  $BA0(B}
\label{sec:hook:prechangegroup}

%This controlling hook is run before Mercurial begins to add a group of
%changesets from another repository.

$B$3$N@)8f%U%C%/$O(BMercurial$B$,0lO"$N%A%'%s%8%;%C%H$rJL$N%j%]%8%H%j$KDI2C$9(B
$B$kA0$K<B9T$5$l$k!%(B

%This hook does not have any information about the changesets to be
%added, because it is run before transmission of those changesets is
%allowed to begin.  If this hook fails, the changesets will not be
%transmitted.

$B$3$N%U%C%/$ODI2C$5$l$k%A%'%s%8%;%C%H$N>pJs$O2?$b;}$?$J$$!%$J$<$J$i$3$N%U%C(B
$B%/$O%A%'%s%8%;%C%H$NAw?.$,;O$^$kA0$K<B9T$5$l$k$+$i$@!%%U%C%/$N<B9T$,<:GT(B
$B$7$?>l9g$O%A%'%s%8%;%C%H$OAw?.$5$l$J$$!%(B

%One use for this hook is to prevent external changes from being added
%to a repository.  For example, you could use this to ``freeze'' a
%server-hosted branch temporarily or permanently so that users cannot
%push to it, while still allowing a local administrator to modify the
%repository.

$B$3$N%U%C%/$r;H$C$F!$30It$NJQ99$,%j%]%8%H%j$KDI2C$5$l$J$$$h$&$K$9$k$3$H(B
$B$b$G$-$k!%Nc$($P!$$3$N%U%C%/$r%5!<%P$GDs6!$5$l$k%V%i%s%A$r0l;~E*$^$?$O1J(B
$BB3E*$K(B``$BE`7k(B''$B$7!$%m!<%+%k$J4IM}<T$O%j%]%8%H%j$rJQ99$G$-$k$,!$%j%b!<%H(B
$B%f!<%6$O$=$N%j%]%8%H%j$K(Bpush$B$G$-$J$$$h$&$K$G$-$k!%(B

%Parameters to this hook:
$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{source}] $BJ8;zNs!%JQ99$N%=!<%9!%>\:Y$K$D$$$F$O(B
	     \ref{sec:hook:sources}$B$r;2>H!%(B
\item[\texttt{url}] URL$B!%%j%b!<%H%j%]%8%H%j$,FCDj$5$l$k>l9g$O$=$N%"%I%l(B
	     $B%9!%>\:Y$K$D$$$F$O(B\ref{sec:hook:url}$B$r;2>H!%(B
\end{itemize}

%See also: \hook{changegroup} (section~\ref{sec:hook:changegroup}),
%\hook{incoming} (section~\ref{sec:hook:incoming}), ,
%\hook{pretxnchangegroup} (section~\ref{sec:hook:pretxnchangegroup})

$B;29M!'(B \hook{changegroup} (\ref{sec:hook:changegroup}$B@a(B)$B!$(B
\hook{incoming} (\ref{sec:hook:incoming}$B@a(B)$B!$(B
\hook{pretxnchangegroup} (\ref{sec:hook:pretxnchangegroup}$B@a(B)

%\subsection{\hook{precommit}---before starting to commit a changeset}
\subsection{\hook{precommit}---$B%A%'%s%8%;%C%H$r%3%_%C%H$9$kA0(B}
\label{sec:hook:precommit}

%This hook is run before Mercurial begins to commit a new changeset.
%It is run before Mercurial has any of the metadata for the commit,
%such as the files to be committed, the commit message, or the commit
%date.

$B$3$N%U%C%/$O(BMercurial$B$,?7$7$$%A%'%s%8%;%C%H$r%3%_%C%H$9$kA0$K<B9T$5$l$k!%(B
$B<B9T$O(BMercurial$B$,%3%_%C%H$5$l$k%U%!%$%kL>!$%3%_%C%H%a%C%;!<%8!$%3%_%C%HF|(B
$B;~$N$h$&$J%3%_%C%H$N$?$a$N%a%?%G!<%?$r;}$DA0$G$"$k!%(B

%One use for this hook is to disable the ability to commit new
%changesets, while still allowing incoming changesets.  Another is to
%run a build or test, and only allow the commit to begin if the build
%or test succeeds.

$B$3$N%U%C%/$r;H$C$F!$30It$+$i$N%A%'%s%8%;%C%H$N<h$j9~$_$r5v2D$9$k0lJ}$G!$(B
$B?7$7$$%A%'%s%8%;%C%H$r%3%_%C%H$G$-$J$$$h$&$K$9$k$3$H$b$G$-$k!%$^$?!$%S%k(B
$B%I$d%F%9%H$r<B9T$7$?$j!$$=$l$,@.8y$7$?;~$N$_%3%_%C%H$r9T$&$h$&$K$9$k$3$H(B
$B$b$G$-$k!%(B

%Parameters to this hook:
$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
%\begin{itemize}
%\item[\texttt{parent1}] A changeset ID.  The changeset ID of the first
%  parent of the working directory.
%\item[\texttt{parent2}] A changeset ID.  The changeset ID of the second
%  parent of the working directory.
%\end{itemize}
\begin{itemize}
\item[\texttt{parent1}] $B%A%'%s%8%;%C%H(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$N(B1$B$DL\$N(B
	     $B?F$N%A%'%s%8%;%C%H(BID$B!%(B
\item[\texttt{parent2}] $B%A%'%s%8%;%C%H(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$N(B2$B$DL\$N(B
	     $B?F$N%A%'%s%8%;%C%H(BID$B!%(B
\end{itemize}
%If the commit proceeds, the parents of the working directory will
%become the parents of the new changeset.

$B%3%_%C%H$,?J9T$9$k$H%o!<%-%s%0%G%#%l%/%H%j$N?F$O?7$7$$%A%'%s%8%;%C%H$N?F(B
$B$H$J$k!%(B

%See also: \hook{commit} (section~\ref{sec:hook:commit}),
%\hook{pretxncommit} (section~\ref{sec:hook:pretxncommit})

$B;29M!'(B\hook{commit} (\ref{sec:hook:commit}$B@a(B)$B!$(B\hook{pretxncommit}
(\ref{sec:hook:pretxncommit}$B@a(B)

%\subsection{\hook{preoutgoing}---before starting to propagate
%changesets}
\subsection{\hook{preoutgoing}---$B%A%'%s%8%;%C%H$rGH5Z$5$;$kA0$K(B}
\label{sec:hook:preoutgoing}

%This hook is invoked before Mercurial knows the identities of the
%changesets to be transmitted.

$B$3$N%U%C%/$O(BMercurial$B$,Aw?.$9$k%A%'%s%8%;%C%H$r<1JL$9$kA0$K<B9T$5$l$k!%(B

%One use for this hook is to prevent changes from being transmitted to
%another repository.

$B$3$N%U%C%/$rMQ$$$F!$B>$N%j%]%8%H%j$XJQ99$rAw?.$7$J$$$h$&$K$9$k$3$H$b$G$-(B
$B$k!%(B

%Parameters to this hook:
$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
%\begin{itemize}
%\item[\texttt{source}] A string.  The source of the operation that is
%  attempting to obtain changes from this repository (see
%  section~\ref{sec:hook:sources}).  See the documentation for the
%  \texttt{source} parameter to the \hook{outgoing} hook, in
%  section~\ref{sec:hook:outgoing}, for possible values of this
%  parameter.
%\item[\texttt{url}] A URL.  The location of the remote repository, if
%  known.  See section~\ref{sec:hook:url} for more information.
%\end{itemize}
\begin{itemize}
\item[\texttt{source}] $BJ8;zNs!%$3$N%j%]%8%H%j$+$iJQ99$r<hF@$7$h$&$H$9$kF0(B
	     $B:n$N%=!<%9!J(B\ref{sec:hook:sources}$B$r;2>H!K!%$3$N%Q%i!<%a%?$,(B
	     $B<h$jF@$kCM$K$D$$$F$O!$(B \ref{sec:hook:outgoing}$B@a$N(B
	     \hook{outgoing}$B%U%C%/$X$N(B\texttt{source}$B%Q%i%a!<%?$N9`L\$r;2(B
	     $B>H$N$3$H!%(B
\item[\texttt{url}] URL$B!%%j%b!<%H%j%]%8%H%j$,FCDj$G$-$k>l9g$O$=$N%"%I%l(B
	     $B%9!%>\:Y$K$D$$$F$O(B\ref{sec:hook:url}$B$r;2>H$N$3$H!%(B
\end{itemize}

%See also: \hook{outgoing} (section~\ref{sec:hook:outgoing})
$B;29M!'(B \hook{outgoing} (\ref{sec:hook:outgoing}$B@a(B)

%\subsection{\hook{pretag}---before tagging a changeset}
\subsection{\hook{pretag}---$B%A%'%s%8%;%C%H$K%?%0$r$D$1$kA0$K(B}
\label{sec:hook:pretag}

%This controlling hook is run before a tag is created.  If the hook
%succeeds, creation of the tag proceeds.  If the hook fails, the tag is
%not created.

$B$3$N@)8f%U%C%/$O%?%0$,:n@.$5$l$kA0$K<B9T$5$l$k!%%U%C%/$N<B9T$,@.8y$7$?>l(B
$B9g$O%?%0$,:n@.$5$l$k!%%U%C%/$N<B9T$,<:GT$7$?>l9g$O%?%0$O:n@.$5$l$J$$!%(B

%Parameters to this hook:
$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
%\begin{itemize}
%\item[\texttt{local}] A boolean.  Whether the tag is local to this
%  repository instance (i.e.~stored in \sfilename{.hg/localtags}) or
%  managed by Mercurial (stored in \sfilename{.hgtags}).
%\item[\texttt{node}] A changeset ID.  The ID of the changeset to be tagged.
%\item[\texttt{tag}] A string.  The name of the tag to be created.
%\end{itemize}

\begin{itemize}
\item[\texttt{local}] $B%V!<%kCM!%?7$7$$%?%0$,8=:_$N%j%]%8%H%j$K%m!<%+%k$J(B
	     $B$b$N(B(\sfilename{.hg/localtags}$B$KJ]B8$5$l$k(B)$B$+(BMercurial$B$G%0%m!<(B
	     $B%P%k$K4IM}$5$l$k$b$N(B(\sfilename{.hgtags}$B$KJ]B8$5$l$k(B)$B$+$r<((B
	     $B$9!%(B
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%%?%0IU$1$5$l$k%A%'%s%8%;%C%H$N(BID.
\item[\texttt{tag}] $BJ8;zNs!%@8@.$5$l$?%?%0$NL>A0!%(B
\end{itemize}

%If the tag to be created is revision-controlled, the \hook{precommit}
%and \hook{pretxncommit} hooks (sections~\ref{sec:hook:commit}
%and~\ref{sec:hook:pretxncommit}) will also be run.

$B@8@.$5$l$?%?%0$,%j%S%8%g%s%3%s%H%m!<%k$5$l$F$$$k>l9g!$(B\hook{precommit}$B%U%C(B
$B%/$H(B\hook{pretxncommit}$B%U%C%/(B(\ref{sec:hook:commit}$B@a$*$h$S(B
\ref{sec:hook:pretxncommit})$B@a(B)$B$NN>J}$,<B9T$5$l$k!%(B

%See also: \hook{tag} (section~\ref{sec:hook:tag})
$B;29M!'(B \hook{tag} (\ref{sec:hook:tag}$B@a(B)

%\subsection{\hook{pretxnchangegroup}---before completing addition of
%remote changesets}
\subsection{\hook{pretxnchangegroup}---$B%j%b!<%H%A%'%s%8%;%C%H$NDI2C$r40(B
  $BN;$9$kA0$K(B}
\label{sec:hook:pretxnchangegroup}

%This controlling hook is run before a transaction---that manages the
%addition of a group of new changesets from outside the
%repository---completes.  If the hook succeeds, the transaction
%completes, and all of the changesets become permanent within this
%repository.  If the hook fails, the transaction is rolled back, and
%the data for the changesets is erased.

$B$3$N@)8f%U%C%/$O!$30It$+$i?7$7$$%A%'%s%8%;%C%H$rDI2C$9$k%H%i%s%6%/%7%g%s(B
$B$,40N;$9$kA0$K<B9T$5$l$k!%%U%C%/$N<B9T$,@.8y$7$?>l9g!$%H%i%s%6%/%7%g%s$O(B
$B40N;$7!$A4$F$N%A%'%s%8%;%C%H$O%j%]%8%H%jFb$G1JB3E*$K$J$k!%%U%C%/$N<B9T$,(B
$B<:GT$7$?>l9g!$%H%i%s%6%/%7%g%s$O%m!<%k%P%C%/$5$l!$%A%'%s%8%;%C%H$N%G!<%?(B
$B$O>C5n$5$l$k!%(B

%This hook can access the metadata associated with the almost-added
%changesets, but it should not do anything permanent with this data.
%It must also not modify the working directory.

$B$3$N%U%C%/$O%H%i%s%6%/%7%g%sCf$N%A%'%s%8%;%C%H$N%a%?%G!<%?$K%"%/%;%9$9$k(B
$B$3$H$,$G$-$k$,!$$3$N%G!<%?$r;H$C$F1JB3E*$J$3$H$O0l@Z$7$F$O$J$i$J$$!%%o!<(B
$B%-%s%0%G%#%l%/%H%j$NJQ99$b$7$F$O$J$i$J$$!%(B

%While this hook is running, if other Mercurial processes access this
%repository, they will be able to see the almost-added changesets as if
%they are permanent.  This may lead to race conditions if you do not
%take steps to avoid them.

$B$3$N%U%C%/$N<B9TCf!$B>$N(BMercurial$B%W%m%;%9$,%j%]%8%H%j$K%"%/%;%9$9$k$H!$%H(B
$B%i%s%6%/%7%g%sCf$N%A%'%s%8%;%C%H$r1JB3E*$J$b$N$H8+$J$92DG=@-$,$"$k!%E,@Z(B
$B$J2sHr:v$r9V$8$J$1$l$P!$$3$l$,6%9g>uBV$r0z$-5/$3$92DG=@-$,$"$k!%(B

%This hook can be used to automatically vet a group of changesets.  If
%the hook fails, all of the changesets are ``rejected'' when the
%transaction rolls back.

$B$3$N%U%C%/$O0lO"$N%A%'%s%8%;%C%H$r<+F0E*$KGS=|$9$k$?$a$K;H$&$3$H$b$G$-(B
$B$k!%$3$N%U%C%/$N<B9T$,<:GT$7$?>l9g!$%H%i%s%6%/%7%g%s$,%m!<%k%P%C%/$5$l$k(B
$B;~$K%A%'%s%8%;%C%HA4BN$,%j%8%'%/%H$5$l$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{node}] A changeset ID.  The changeset ID of the first
%  changeset in the group that was added.  All changesets between this
%  and \index{tags!\texttt{tip}}\texttt{tip}, inclusive, were added by
%  a single \hgcmd{pull}, \hgcmd{push} or \hgcmd{unbundle}.
%\item[\texttt{source}] A string.  The source of these changes.  See
%  section~\ref{sec:hook:sources} for details.
%\item[\texttt{url}] A URL.  The location of the remote repository, if
%  known.  See section~\ref{sec:hook:url} for more information.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%DI2C$5$l$k0lO"$N%A%'%s%8%;%C%H$N(B
	     $B$&$A!$:G=i$N%A%'%s%8%;%C%H(BID$B!%$3$l$H(B
	     \index{tags!\texttt{tip}}\texttt{tip}$B$N4V$NA4$F$N%A%'%s%8%;%C(B
	     $B%H$,0lEY$N(B\hgcmd{pull}, \hgcmd{push} $B$^$?$O(B
\item[\texttt{source}] $BJ8;zNs!%$3$l$i$NJQ99$N%=!<%9!%>\:Y$K$D$$$F$O(B
	     \ref{sec:hook:sources}$B@a$r;2>H$N$3$H!%(B
\item[\texttt{url}] URL$B!%4{CN$N%j%b!<%H%j%]%8%H%j$N>l=j!%>\:Y$K$D$$$F$O(B
	     \ref{sec:hook:url}$B@a$r;2>H$N$3$H!%(B
\end{itemize}

%See also: \hook{changegroup} (section~\ref{sec:hook:changegroup}),
%\hook{incoming} (section~\ref{sec:hook:incoming}),
%\hook{prechangegroup} (section~\ref{sec:hook:prechangegroup})

$B;29M!'(B \hook{changegroup} (\ref{sec:hook:changegroup}$B@a(B),
\hook{incoming} (\ref{sec:hook:incoming}$B@a(B),
\hook{prechangegroup} (\ref{sec:hook:prechangegroup}$B@a(B)

%\subsection{\hook{pretxncommit}---before completing commit of new
%changeset}
\subsection{\hook{pretxncommit}---$B?7$7$$%A%'%s%8%;%C%H$N%3%_%C%H$r40N;$9(B
  $B$kA0$K(B}
\label{sec:hook:pretxncommit}

%This controlling hook is run before a transaction---that manages a new
%commit---completes.  If the hook succeeds, the transaction completes
%and the changeset becomes permanent within this repository.  If the
%hook fails, the transaction is rolled back, and the commit data is
%erased.

$B$3$N@)8f%U%C%/$O?7$?$J%3%_%C%H$N$?$a$N%H%i%s%6%/%7%g%s$N40N;A0$K<B9T$5$l(B
$B$k!%$3$N%U%C%/$N<B9T$,@.8y$7$?>l9g!$%H%i%s%6%/%7%g%s$,40N;$5$l!$%A%'%s%8(B
$B%;%C%H$O%j%]%8%H%jFb$G1JB3E*$K$J$k!%%U%C%/$N<B9T$,<:GT$7$?>l9g$O%H%i%s%6(B
$B%/%7%g%s$O%m!<%k%P%C%/$5$l!$%3%_%C%H%G!<%?$O>C5n$5$l$k!%(B

%This hook can access the metadata associated with the almost-new
%changeset, but it should not do anything permanent with this data.  It
%must also not modify the working directory.

$B$3$N%U%C%/$O%H%i%s%6%/%7%g%sCf$N%A%'%s%8%;%C%H$N%a%?%G!<%?$K%"%/%;%9$9$k(B
$B$3$H$,$G$-$k$,!$$3$N%G!<%?$r;H$C$F1JB3E*$J$3$H$O0l@Z$7$F$O$J$i$J$$!%%o!<(B
$B%-%s%0%G%#%l%/%H%j$NJQ99$b$7$F$O$J$i$J$$!%(B

%While this hook is running, if other Mercurial processes access this
%repository, they will be able to see the almost-new changeset as if it
%is permanent.  This may lead to race conditions if you do not take
%steps to avoid them.

$B$3$N%U%C%/$N<B9TCf!$B>$N(BMercurial$B%W%m%;%9$,%j%]%8%H%j$K%"%/%;%9$9$k$H!$%H(B
$B%i%s%6%/%7%g%sCf$N%A%'%s%8%;%C%H$r1JB3E*$J$b$N$H8+$J$92DG=@-$,$"$k!%E,@Z(B
$B$J2sHr:v$r9V$8$J$1$l$P!$$3$l$,6%9g>uBV$r0z$-5/$3$92DG=@-$,$"$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{node}] A changeset ID.  The changeset ID of the newly
%  committed changeset.
%\item[\texttt{parent1}] A changeset ID.  The changeset ID of the first
%  parent of the newly committed changeset.
%\item[\texttt{parent2}] A changeset ID.  The changeset ID of the second
%  parent of the newly committed changeset.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$K$38+$s$H$5$l$?%A%'%s%8%;%C(B
	     $B%H$N(BID$B!%(B
\item[\texttt{parent1}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$K%3%_%C%H$5$l$?%A%'%s%8%;%C(B
	     $B%H$N(B1$B$DL\$N?F$N%A%'%s%8%;%C%H(BID$B!%(B
\item[\texttt{parent2}] $B%A%'%s%8%;%C%H(BID$B!%?7$?$K%3%_%C%H$5$l$?%A%'%s%8%;%C(B
	     $B%H$N(B2$B$DL\$N?F$N%A%'%s%8%;%C%H(BID$B!%(B
\end{itemize}

%See also: \hook{precommit} (section~\ref{sec:hook:precommit})
$B;29M!'(B\hook{precommit} (\ref{sec:hook:precommit}$B@a(B)

%\subsection{\hook{preupdate}---before updating or merging working
%directory}
\subsection{\hook{preupdate}---$B%o!<%-%s%0%G%#%l%/%H%j$N%"%C%W%G!<%H$^$?(B
  $B$O%^!<%8$NA0$K(B}
\label{sec:hook:preupdate}

%This controlling hook is run before an update or merge of the working
%directory begins.  It is run only if Mercurial's normal pre-update
%checks determine that the update or merge can proceed.  If the hook
%succeeds, the update or merge may proceed; if it fails, the update or
%merge does not start.

$B$3$N@)8f%U%C%/$O%o!<%-%s%0%G%#%l%/%H%j$N%"%C%W%G!<%H$^$?$O%^!<%8$,;O$^$k(B
$BA0$K<B9T$5$l$k!%(B Mercurial$B$NDL>o$N%"%C%W%G!<%HA0%A%'%C%/$,%"%C%W%G!<%H$^(B
$B$?$O%^!<%8$r<B9T$G$-$k$HH=CG$7$?>l9g$K$N$_<B9T$5$l$k!%%U%C%/$N<B9T$,@.8y(B
$B$7$?>l9g!$%"%C%W%G!<%H$^$?$O%^!<%8$,9T$o$l$k!%<:GT$7$?>l9g$O%"%C%W%G!<%H(B
$B$^$?$O%^!<%8$O3+;O$5$l$J$$!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{parent1}] A changeset ID.  The ID of the parent that the
%  working directory is to be updated to.  If the working directory is
%  being merged, it will not change this parent.
%\item[\texttt{parent2}] A changeset ID.  Only set if the working
%  directory is being merged.  The ID of the revision that the working
%  directory is being merged with.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{parent1}] $B%A%'%s%8%;%C%H(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$,%"%C%W(B
	     $B%G!<%H$5$l$k?F(BID.$B%o!<%-%s%0%G%#%l%/%H%j$,%^!<%8$5$l$k>l9g!$(B
	     $B?F(BID$B$OJQ99$5$l$J$$!%(B
\item[\texttt{parent2}] $B%A%'%s%8%;%C%H(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$,%^!<%8(B
	     $B$5$l$k>l9g$N$_%;%C%H$5$l$k!%%o!<%-%s%0%G%#%l%/%H%j$,%^!<%8(B
	     $B$5$l$k%j%S%8%g%s(BID$B!%(B
\end{itemize}

%See also: \hook{update} (section~\ref{sec:hook:update})

$B;29M!'(B \hook{update} (\ref{sec:hook:update}$B@a(B)

%\subsection{\hook{tag}---after tagging a changeset}
\subsection{\hook{tag}---$B%A%'%s%8%;%C%H$K%?%0IU$1$7$?8e$K(B}
\label{sec:hook:tag}

%This hook is run after a tag has been created.
$B$3$N%U%C%/$O%?%0$,@8@.$5$l$?8e$K<B9T$5$l$k!%(B

%Parameters to this hook:
%\begin{itemize}
%\item[\texttt{local}] A boolean.  Whether the new tag is local to this
%  repository instance (i.e.~stored in \sfilename{.hg/localtags}) or
%  managed by Mercurial (stored in \sfilename{.hgtags}).
%\item[\texttt{node}] A changeset ID.  The ID of the changeset that was
%  tagged.
%\item[\texttt{tag}] A string.  The name of the tag that was created.
%\end{itemize}

$B$3$N%U%C%/$X$N%Q%i%a!<%?!'(B
\begin{itemize}
\item[\texttt{local}] $B%V!<%kCM!%?7$7$$%?%0$,8=:_$N%j%]%8%H%j$K%m!<%+%k$J(B
	     $B$b$N(B(\sfilename{.hg/localtags}$B$KJ]B8$5$l$k(B)$B$+(BMercurial$B$K%0%m!<(B
	     $B%P%k$K4IM}$5$l$k$b$N(B(\sfilename{.hgtags}$B$KJ]B8$5$l$k(B)$B$+$r<((B
	     $B$9!%(B
\item[\texttt{node}] $B%A%'%s%8%;%C%H(BID$B!%%?%0IU$1$5$l$k%A%'%s%8%;%C%H$N(BID.
\item[\texttt{tag}] $BJ8;zNs!%@8@.$5$l$?%?%0$NL>A0!%(B
\end{itemize}

%If the created tag is revision-controlled, the \hook{commit} hook
%(section~\ref{sec:hook:commit}) is run before this hook.

$B@8@.$5$l$?%?%0$,%j%S%8%g%s%3%s%H%m!<%k$5$l$F$$$k>l9g!$(B\hook{commit}$B%U%C(B
$B%/(B(\ref{sec:hook:commit}$B@a(B)$B$O$3$N%U%C%/$NA0$K<B9T$5$l$k!%(B

%See also: \hook{pretag} (section~\ref{sec:hook:pretag})

$B;29M!'(B \hook{pretag} (\ref{sec:hook:pretag}$B@a(B)

%\subsection{\hook{update}---after updating or merging working
%directory}
\subsection{\hook{update}---$B%o!<%-%s%0%G%#%l%/%H%j$r99?7$^$?$O%^!<%8$7$?(B
  $B8e$K(B}
\label{sec:hook:update}

%This hook is run after an update or merge of the working directory
%completes.  Since a merge can fail (if the external \command{hgmerge}
%command fails to resolve conflicts in a file), this hook communicates
%whether the update or merge completed cleanly.

$B$3$N%U%C%/$O%o!<%-%s%0%G%#%l%/%H%j$N%"%C%W%G!<%H$^$?$O%^!<%8$,40N;$7$?8e(B
$B$K<B9T$5$l$k!%%^!<%8$O<:GT$9$k$3$H$b$"$k!J30It$N(B\command{hgmerge}$B%3%^%s%I(B
$B$O%U%!%$%kFb$N%3%s%U%j%/%H$r2r7h$G$-$J$$$3$H$,$"$k!K$N$G!$$3$N%U%C%/$O%"%C(B
$B%W%G!<%H$^$?$O%^!<%8$,@5>o$K40N;$7$?$+$I$&$+$rLd$$9g$o$;$k!%(B

%\begin{itemize}
%\item[\texttt{error}] A boolean.  Indicates whether the update or
%  merge completed successfully.
%\item[\texttt{parent1}] A changeset ID.  The ID of the parent that the
%  working directory was updated to.  If the working directory was
%  merged, it will not have changed this parent.
%\item[\texttt{parent2}] A changeset ID.  Only set if the working
%  directory was merged.  The ID of the revision that the working
%  directory was merged with.
%\end{itemize}

\begin{itemize}
\item[\texttt{error}] $B%V!<%kCM!%%"%C%W%G!<%H$^$?$O%^!<%8$,@5>o$K40N;$7$?(B
	     $B$+$I$&$+$r<($9!%(B
\item[\texttt{parent1}] $B%A%'%s%8%;%C%H(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$,%"%C%W(B
	     $B%G!<%H$5$l$k?F(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$,%^!<%8$5$l$k>l9g!$?F(B
	     ID$B$OJQ2=$7$J$$!%(Bxxx
\item[\texttt{parent2}] $B%A%'%s%8%;%C%H(BID$B!%%o!<%-%s%0%G%#%l%/%H%j$,%^!<%8(B
	     $B$5$l$k;~$N$_%;%C%H$5$l$k!%%o!<%-%s%0%G%#%l%/%H%j$,%^!<%8$5$l(B
	     $B$k%j%S%8%g%s(BID$B!%(B
\end{itemize}

%See also: \hook{preupdate} (section~\ref{sec:hook:preupdate})
$B;29M(B: \hook{preupdate} (\ref{sec:hook:preupdate}$B@a(B)

%%% Local Variables:
%%% mode: yatex
%%% TeX-master: "00book"
%%% End: