Mercurial > hgbook
view ja/hook.tex @ 800:1a30d2627512
Propagate 2ff0a43f1152
Update ch03
| author | Yoshiki Yazawa <yaz@honeyplanet.jp> |
|---|---|
| date | Thu, 18 Jun 2009 20:04:44 +0900 |
| parents | 2a93b1d35990 |
| children | 8a3041e6f3cb |
line wrap: on
line source
%\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$NL5%m%C%/FI$_=P$7(B $B$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 <joe.user@domain.com> in % the frobnitz repository, refers to this bug. % % For complete details, see % http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a % % Changeset description: % Fix bug 10483 by guarding against some NULL pointers %\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 <joe.user@domain.com> in the frobnitz repository, refers to this bug. For complete details, see http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a Changeset description: Fix bug 10483 by guarding against some NULL pointers \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 nobody@nowhere.com % \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 nobody@nowhere.com \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!%(B $B$3$N5sF0$,K>$^$7$/$J$$>l9g$O!$(B\rcsection{usermap}$B%;%/%7%g%s$r$;$C$F$$$9$k(B $B$3$H$G%3%_%C%?$N(Bemail$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] % jane.user@example.com = 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] % stephanie@example.com = 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] jane.user@example.com = 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" nobody@example.com %\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" nobody@example.com \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 john.q.public@example.com %\end{codesample2} %What this means is that the committer's address, %\texttt{john.q.public@example.com}, 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 john.q.public@example.com \end{codesample2} $B$N$h$&$JFbMF$G$"$k!%$3$l$O!$%3%_%C%?$N%"%I%l%9(B \texttt{john.q.public@example.com}$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-JS%9%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$K$D$$$+$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$,%j%]%8%H%j%m!<%+%k$J$b$N(B (\sfilename{.hg/localtags}$B$KJ]B8$5$l$k(B)$B$+(BMercurial$B$K4IM}(B $B$5$l$k$b$N(B(\sfilename{.hgtags}$B$KJ]B8$5$l$k(B)$B$+$r<($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$,%j%]%8%H%j%m!<%+%k$J$b$N(B (\sfilename{.hg/localtags}$B$KJ]B8$5$l$k(B)$B$+(BMercurial$B$K4IM}(B $B$5$l$k$b$N(B(\sfilename{.hgtags}$B$KJ]B8$5$l$k(B)$B$+$r<($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: