comparison ja/hook.tex @ 383:ef0c1fb05c84

more hook.tex

382:d64d38d2a91a

$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}

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

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}

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).

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.

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.

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]

\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.

%\subsection{\hgext{bugzilla}---integration with Bugzilla}
\subsection{\hgext{bugzilla}---Bugzilla$B$X$NE}9g(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.

It adds a comment to the bug that looks like this (you can configure
the contents of the comment---see below):
\begin{codesample2}
  Changeset aad8b264143a, made by Joe User <[e-mail]> in
  the frobnitz repository, refers to this bug.

  For complete details, see
  http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a

  Changeset description:
        Fix bug 10483 by guarding against some NULL pointers
\end{codesample2}
The value of this hook is that it automates the process of updating a
bug any time a changeset refers to it.  If you configure the hook
properly, it makes it easy for people to browse straight from a
Bugzilla bug to a changeset that refers to that bug.

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}

%\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}

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.

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}.

Configuration information for this hook lives in the
\rcsection{bugzilla} section of your \hgrc.
\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}{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}{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}{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}{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}{notify}] If you want Bugzilla to send out a
  notification email to subscribers after this hook has added a
  comment to a bug, you will need this hook to run a command whenever
  it updates the database.  The command to run depends on where you
  have installed Bugzilla, but it will typically look something like
  this, if you have Bugzilla installed in
  \dirname{/var/www/html/bugzilla}:
  \begin{codesample4}
    cd /var/www/html/bugzilla && ./processmail %s [e-mail]
  \end{codesample4}
  The Bugzilla \texttt{processmail} program expects to be given a
  bug~ID (the hook replaces ``\texttt{\%s}'' with the bug~ID) and an
  email address.  It also expects to be able to write to some files in
  the directory that it runs in.  If Bugzilla and this hook are not
  installed on the same machine, you will need to find a way to run
  \texttt{processmail} on the server where Bugzilla is installed.
\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.

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

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

383:ef0c1fb05c84

$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]

\end{codesample2}

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

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

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

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

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

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

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

%It adds a comment to the bug that looks like this (you can configure
%the contents of the comment---see below):
%\begin{codesample2}
%  Changeset aad8b264143a, made by Joe User <[e-mail]> in
%  the frobnitz repository, refers to this bug.
%
%  For complete details, see
%  http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a
%
%  Changeset description:
%        Fix bug 10483 by guarding against some NULL pointers
%\end{codesample2}
%The value of this hook is that it automates the process of updating a
%bug any time a changeset refers to it.  If you configure the hook
%properly, it makes it easy for people to browse straight from a
%Bugzilla bug to a changeset that refers to that bug.

$B$3$N%U%C%/$O<!$N$h$&$K%P%0$X%3%a%s%H$rDI2C$9$k!%!J%3%a%s%H$NFbMF$O@_Dj2D(B
$BG=$G$"$k!%$3$l$K$D$$$F$O2<5-$r;2>H!%!K(B
\begin{codesample2}
  Changeset aad8b264143a, made by Joe User <[e-mail]> in
  the frobnitz repository, refers to this bug.

  For complete details, see
  http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a

  Changeset description:
        Fix bug 10483 by guarding against some NULL pointers
\end{codesample2}
$B$3$N%U%C%/$O!$%A%'%s%8%;%C%H$,%P%0$r;2>H$7$?>l9g!$%P%0$N99?7$r<+F02=$G$-(B
$B$k$H$3$m$K2ACM$,$"$k!%$3$N%U%C%/$r$-$A$s$H@_Dj$9$l$P!$(BBugzilla$B%P%0$r1\Mw(B
$B$7$F$$$k%f!<%6$,!$%P%0$+$iD>$A$K4X78$9$k%A%'%s%8%;%C%H$r;2>H$G$-$k$h$&$K(B
$B$J$k!%(B

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$B%G%U%)%k%H$G$O(B\hgext{bugzilla}$B%U%C%/$O%P%0$r99?7$9$k(BBugzilla$B%f!<%6L>$H$7(B
$B$F%A%'%s%8%;%C%H$N%3%_%C%?$N(Bemail$B%"%I%l%9$r;H$*$&$H$9$k!%(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]
%  [e-mail] = jane
%\end{codesample2}
%You can either keep the \rcsection{usermap} data in a normal \hgrc, or
%tell the \hgext{bugzilla} hook to read the information from an
%external \filename{usermap} file.  In the latter case, you can store
%\filename{usermap} data by itself in (for example) a user-modifiable
%repository.  This makes it possible to let your users maintain their
%own \rcitem{bugzilla}{usermap} entries.  The main \hgrc\ file might
%look like this:
%\begin{codesample2}
%  # regular hgrc file refers to external usermap file
%  [bugzilla]
%  usermap = /home/hg/repos/userdata/bugzilla-usermap.conf
%\end{codesample2}
%While the \filename{usermap} file that it refers to might look like
%this:
%\begin{codesample2}
%  # bugzilla-usermap.conf - inside a hg repository
%  [usermap]
%  [e-mail] = steph
%\end{codesample2}

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

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