%\chapter{Handling repository events with hooks}
\chapter{リポジトリイベントをフックで取り扱う}
\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は，リポジトリに起こるイベントに対して自動化されたアクションを行
う強力なメカニズムを持っている．いくつかのイベントに対しては，Mercurialの
反応を制御することもできる．

%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は\emph{フック}と呼ばれる機構を使ってアクションを行う．フックは
他のリビジョンコントロールシステムでは``トリガ''と呼ばれることもあるが，
これらは実際は同じものである．

%\section{An overview of hooks in Mercurial}
\section{Mercurialでのフックの概要}

%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がサポートするフックの一部を列挙する．個々のフックについては
後ほどsection~\ref{sec:hook:ref}で詳細に触れる．

\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}] チェンジセットグループが外部からリポジト
	     リに加わった後で呼び出される．

%\item[\small\hook{commit}] This is run after a new changeset has been
%  created in the local repository.
\item[\small\hook{commit}] ローカルリポジトリで新しいチェンジセットが作
	     成された後に呼び出される．

%\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}] 新しいチェンジセットが外部からリポジトリに加
	     わる毎に呼び出される．\emph{group}が加わる毎に呼び出されるフッ
	     クに\hook{changegroup}フックがある．

%\item[\small\hook{outgoing}] This is run after a group of changesets
%  has been transmitted from this repository.
\item[\small\hook{outgoing}] リポジトリからチェンジセットグループが外部
	     に送信された後に呼び出される．

%\item[\small\hook{prechangegroup}] This is run before starting to
%  bring a group of changesets into the repository.
\item[\small\hook{prechangegroup}] チェンジセットグループをリポジトリか
	     ら外部に持ち出す前に呼び出される．

%\item[\small\hook{precommit}] Controlling. This is run before starting
%  a commit.
\item[\small\hook{precommit}] Controlling. コミットが始まる前に呼び出さ
	     れる．

%\item[\small\hook{preoutgoing}] Controlling. This is run before
%  starting to transmit a group of changesets from this repository.
\item[\small\hook{preoutgoing}] Controlling. チェンジセットグループをリ
	     ポジトリから外部に送信する前に呼び出される．

%\item[\small\hook{pretag}] Controlling. This is run before creating a tag.
\item[\small\hook{pretag}] Controlling. タグが作成される前に呼び出される．

%\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. チェンジセットグループ
	     が外部からローカルリポジトリに加わった後，永続的に記録するた
	     めのトランザクションが完了する前に呼び出される．

%\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. 新しいチェンジセットがロー
	     カルリポジトリで作成された後，永続的に記録するためのトランザ
	     クションが完了する前に呼び出される．

%\item[\small\hook{preupdate}] Controlling. This is run before starting
%  an update or merge of the working directory.
\item[\small\hook{preupdate}] Controlling. ワーキングディレクトリの更新
	     またはマージが行われる前に呼び出される．

%\item[\small\hook{tag}] This is run after a tag is created.
\item[\small\hook{tag}] タグが作成された後で呼び出される．

%\item[\small\hook{update}] This is run after an update or merge of the
%  working directory has finished.
\item[\small\hook{update}] ワーキングディレクトリの更新かマージが完了し
	     た時に呼び出される．
\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.

フックのうち，説明が``Controlling''という語で始まるものは，フックの成否を
判定し，以後の動作を行うかどうか決定する機能がある．フックが成功すると動
作は先へ進む．フックが成功しなかった場合は以後の動作は実行が許可されない
か，動作が完了せず終る．

%\section{Hooks and security}
\section{フックとセキュリティ}

%\subsection{Hooks are run with your privileges}
\subsection{フックはユーザの権限で動作する}

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

リポジトリ内でMercurialコマンドを実行し，コマンドがフックを呼び出した場
合，フックは\emph{操作者}のシステムで，\emph{操作者}の特権レベルで動作す
る．フックは任意の実行コードなので，相応の留意が必要である．フックを作っ
たのが誰で，そのフックが何をするのかきちんと理解することなしにフックをイ
ンストールしてはならない．

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

自分でインストールしたのではないフックを実行させてしまうことも有り得る．
他所のシステムの上でMercurialを使う場合，Mercurialがシステムワイドの
\hgrc\ ファイルで定義されたフックを起動する可能性がある．

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

他のユーザが所有するリポジトリで作業する場合，Mercurialは所有者のリポジ
トリ内で定義されたフックを実行し得るが，実行権限はあなたのもので行われる．
例えばそのリポジトリから\hgcmd{pull}を行うとき，リポジトリ内の
\sfilename{.hg/hgrc}ファイルでローカルな\hook{outgoing}フックが定義されて
いると，あなたはそのリポジトリを所有していないにもかかわらずそのフックは
あなたの権限で実行される．

%\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}
これはローカルなリポジトリやネットワークファイルシステム上のリポジトリか
 らpullした場合にのみ適用される．httpまたはsshを使ってpullした場合，すべ
 ての\hook{outgoing}フックはサーバ上でサーバプロセスを実行しているアカウ
 ントの権限で実行される．
\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 リポジトリ内で定義されているフックを見るには
\hgcmdargs{config}{hooks}コマンドを使う．あるリポジトリで作業していて，新
しいコードを他のリポジトリから入手するために通信を行う場合（例えば
\hgcmd{pull}か\hgcmd{incoming}を実行する） ，チェックすべきフックは手元の
リポジトリのものではなく，リモートのリポジトリのフックである．

%\subsection{Hooks do not propagate}
\subsection{フックは伝播しない}

%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では，フックはリビジョン管理されず，リポジトリからクローンしたり
pullしても伝播しない．こうなっている理由は単純で，フックは任意の実行可能
コードであるからである．フックはあなたのマシンの上であなたのユーザーIDと
特権レベルで動作で動く．

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

分散リビジョンコントロールシステムにリビジョン管理されたフックを実装する
のはとても無謀である．このような機構があるとリビジョンコントロールシステ
ムのユーザアカウントを偽装するような仕掛けを簡単に実現できてしまう．

%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はフックを伝播させないので，共通のプロジェクトで他の開発者と協力
している場合，彼らはあなたが使ってるのと同じMercurialフックを使っていると
仮定したり，彼らのリポジトリでもフックが同様に正しく設定されていると仮定
すべきではない．彼らがフックを使うように望むのであれば，使用法についてド
キュメントを作成すべきである．

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

企業内のイントラネットではコントロールは幾分簡単である． NFSファイルシス
テム上でMercurialの``標準''インストレーション例を提供し，すべてのユーザが
参照するサイトワイドの\hgrc\ ファイルを用意し，その中でフックを定義するこ
とができる．しかしこの方法にも下記のような欠点がある．

%\subsection{Hooks can be overridden}
\subsection{フックはオーバライド可能である}

%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では，フックを再定義することによって，既存のフック定義をオーバラ
イドすることができる．これは変数を空の文字列にしたり，挙動を変更すること
で禁止することができる．

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

フックを定義したシステムワイドまたはサイトワイドの\hgrc\ ファイルを使用し
ても，リポジトリのユーザがフックを禁止したりオーバライドできてしまうのに
気付くだろう．

%\subsection{Ensuring that critical hooks are run}
\subsection{クリティカルなフックが確実に実行されるようにする}

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

時には他の開発者が回避策をとれないようなポリシーを要請したい場合があるだ
ろう．例えばすべてのチェンジセットが厳格なテストセットにパスすることを必
要とする場合が考えられる．これをサイトワイドの\hgrc\ でフックとして定義
した場合，これはラップトップを使っているリモートユーザには機能しないし，
フックをオーバライドできるため，ローカルユーザにとっても無視できてしまう．

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

その代わり，Mercurialの使用に関するポリシーを設定し，適切に設定され，厳重
に管理された既知の``カノニカル''サーバを通じて変更が波及するようにするこ
とができる．

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

これを実現する一法はソーシャルエンジニアリングと技術の組み合わせで行う方
法である．限定アクセスアカウントを設定し，このアカウントで管理されている
リポジトリに対してユーザは変更をネットワークを介してpushできる．しかしユー
ザはこのアカウントでログインしたり，通常のシェルコマンドを実行することは
できない．このシナリオでは，ユーザはどんな古いゴミを含んだチェンジセット
でもコミットすることができる．

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

多くのユーザがpullするサーバに誰かがチェンジセットをpushした場合，サーバ
はチェンジセットを恒久的に受け入れる前にチェックを行い，一連のテストをパ
スできなければリジェクトを行う．ユーザがこのフィルタサーバからのみpullを
行うのであれば，全ての変更は自動的に全て検査されていることになる．

%\section{Care with \texttt{pretxn} hooks in a shared-access repository}
\section{共有アクセスリポジトリで\texttt{pretxn}フックを使う}

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

複数のユーザが共有アクセスを行うリポジトリで，自動化された作業を行うため
にフックを使用したいなら，どのように行うか注意深く考える必要がある．

%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はリポジトリに書き込みを行うときにだけリポジトリをロックする．
またMercurialの書き込みを行う部分のみがロックを考慮する．書き込みロック
は，複数の同時書き込みが他の変更を上書きし，リポジトリを破損するのを防ぐ．

%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はデータの読み書きの順序を注意深く行うため，リポジトリからのデー
タ読み出しの際にロックを取得する必要がない． Mercurialのリポジトリから読
み出しを行う部分は，ロックを全く気にする必要がない．この無ロック読み出し
によって，同時実行性と性能を大幅に高めている．

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

しかしながらこの高性能はそれを知らなければ問題を引き起こすあるトレードオ
フをももたらす．これを説明するために，Mercurialがどのようにチェンジセット
をリポジトリに追加し，それらを読み出すかの詳細に触れなければならない．

%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はメタデータを\emph{書き込む}とき，直接目的のファイルに書き込み
する．Mercurialはまずファイルデータを書き込み，次いで（新しいファイルデー
タの場所を示すポインタを含む）マニフェストデータを書き込む．そして（新し
いマニフェストデータの場所を示すポインタを含む）チェンジログデータを書き
込む．各々のファイルへの最初の書き込みの前に，ファイルの末尾のレコードを
トランザクションログに保存する．トランザクションがロールバックされる場合
は，Mercurialは各々のファイルをトランザクションが始まる前のサイズに切り詰
める．

%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はメタデータを\emph{読む}時にまずチェンジログを読み，次いで残り
の部分を読む．リーダはチェンジログに現れるマニフェストの一部またはファイ
ルメタデータの一部にのみアクセスするため，部分的に書かれたデータを見るこ
とはできない．

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

いくつかの制御フック（\hook{pretxncommit}と\hook{pretxnchangegroup}）はト
ランザクションがほぼ完了した時に実行される．すべてのメタデータが書き込ま
れるが，この時点でもMercurialはトランザクションを元に戻すことができ，その
場合は新しく書かれたデータは消失する．

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

これらのフックのうち1つが長時間にわたって実行されていると，リーダがチェン
ジセットのメタデータを読むことのできるタイムウィンドウが開く．このチェン
ジセットはまだ永続的なものになっておらず，従って実在すると考えるべきでは
ないものである．フックが実行されている時間が長くなればなるほど，タイムウィ
ンドウが開く時間も長くなる．

%\subsection{The problem illustrated}
\subsection{問題の詳細}

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

実用における\hook{pretxnchangegroup}フックの良い使用法としては，到着した
変更が中央のリポジトリに取り込まれる前に自動でビルドとテストを行うことが
考えられる．これにより，ビルドを妨げる変更は誰もリポジトリにpushできない
ことが確実になる．クライアントがテスト中に変更をpullすることができれば，
このテストの有用性はゼロになってしまう．疑いを持たずに誰かがテストされて
いない変更をpullできるのであれば，彼らのビルドは失敗する可能性がある．

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

この問題への技術的に最も安全な回答は，``門番''リポジトリを\emph{一方向}に
設定することである．リポジトリを外部からpushされた変更を受け取るが，誰も
pullできないように設定する（\hook{preoutgoing}フックを使ってリポジトリを
ロックする）．\hook{changegroup}フックを設定し，ビルドやテストが成功した
ときに限って，フックが新たな変更をユーザのpull\emph{できる}別のリポジト
リにpushするようにする．

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

実際上は，このように集中したボトルネックを置くことは良い考えとは言えず，
トランザクションの可視性は全くない．プロジェクトのサイズおよびビルドとテ
ストに要する時間が増加するに従って，このような``事前に試す''手法は壁に突
き当たる．テストに使える時間で捌き切れないほどのチェンジセットを試さなけ
ればならなくなるからである．フラストレーションが貯るのは避けられないだろ
う．

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

よりスケールする手法は，開発者にpush前のビルドとテストをさせることであ
る．中央で自動によるビルドとテストを行うのは，push\emph{後}に，全てに問題
がないことを確認するために行う．このアプローチの利点はリポジトリが変更を
受け入れるペースに何も制限を課さないことである．

%\section{A short tutorial on using hooks}
\section{フックの使用法}
\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フックを書くのは容易い．ここでは\hgcmd{commit}コマンドが終了し
た際に，作成されたチェンジセットのハッシュ値を表示するくフックを書いてみ
よう．このフックを\hook{commit}と呼ぶことにする．

\begin{figure}[ht]
  \interaction{hook.simple.init}
%  \caption{A simple hook that runs when a changeset is committed}
  \caption{チェンジセットがコミットされた時に動作する単純なフック}
  \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).

全てのフックは例~\ref{ex:hook:init}と同じパターンになる． \hgrc ファイルの
\rcsection{hooks}セクションにエントリを追加する．左辺にトリガーとなるベン
トを記述し，右辺に対応するアクションを記述する．例に示した通り，フックに
は任意のシェルコマンドを書くことができる．環境変数を設定することで
Mercurialからフックに追加の情報を渡すことができる．（例の
\envar{HG\_NODE}を参照．）

%\subsection{Performing multiple actions per event}
\subsection{1つのイベントに複数のアクションを行う}

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

例~\ref{ex:hook:ext}に示したように，特定のイベントに2つ以上のフックを定義
することが必要になることが多いだろう． Mercurialでは，フック名の最後に
\emph{拡張子}を追加することでこれが可能になる．拡張子を付けるに
は，``\texttt{.}'' 文字と，これに続く何文字かからなる名前をフックにつけれ
ばよい．例えばMercurialは\texttt{commit}イベントが起きた時に
\texttt{commit.foo}と\texttt{commit.bar}フックの両方を呼び出す．

\begin{figure}[ht]
  \interaction{hook.simple.ext}
%  \caption{Defining a second \hook{commit} hook}
  \caption{2番目の\hook{commit}フックを定義する}
  \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つのイベントに複数のフックが定義されている時，Mercurialはフックを拡張子
でソートし，ソートされた順序に従ってフックを実行する．上記の例では
\texttt{commit}，\texttt{commit.bar}，\texttt{commit.foo}の順に実行する．

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

新しいフックを定義する時に，内容を説明するような拡張子を付けるのはよい考
えである．こうすることによって，フックの目的が何なのかを覚えやすくなる．
フックが失敗した場合，エラーメッセージにはフック名と拡張子が含まれる．説
明的な拡張子はフックが失敗した理由を知るよい手がかりとなる．（例
は~\ref{sec:hook:perm}を参照のこと．）

%\subsection{Controlling whether an activity can proceed}
\subsection{動作が進行できるかどうか制御する}
\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.

前の例ではコミットが完了した後に実行される\hook{commit}フックを用いた．こ
れはMercurialフックのうち，動作が終了した後に実行されるもののうちの1つで
ある．このようなフックは，Mercurialの動作そのものに影響を及ぼさない．

%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は動作の開始前や，開始後終了するまでの間に発生するイベントを多数
定義している．これらのイベントでトリガーされるフックは，動作を続行するか
中断するか決めることができる．

%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}フックはコミット後，コミットの完了前に呼び出される．
言い替えると，チェンジセットを示すメタデータがディスクに書き込まれた後
で，トランザクションが完了する前に呼び出される．
\hook{pretxncommit}フックはトランザクションを完了するか，ロールバックす
るかを決定する機能がある．

%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}フックがステータスコード0で終了するとトランザクション
は完了することができ，コミットが終了し，\hook{commit}フックが呼び出される．
\hook{pretxncommit}フックが非0のステータスコードで終了すると，トランザク
ションはロールバックされ，チェンジセットを示すメタデータは消去される．こ
の場合\hook{commit}フックは呼び出されない．

\begin{figure}[ht]
  \interaction{hook.simple.pretxncommit}
%  \caption{Using the \hook{pretxncommit} hook to control commits}
  \caption{コミットを制御するために\hook{pretxncommit}フックを使用する}
  \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}はコミットコメントがバグIDを含むかをチェック
する．もし含まれればコミットは完了する．含まない場合はコミットはロールバッ
クされる．

%\section{Writing your own hooks}
\section{オリジナルのフックを書く}

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

フックを書く場合，Mercurialを\hggopt{-v}オプションを付けたり
\rcitem{ui}{verbose}設定項目を``true''に設定することは役に立つ．この場
合，Mercurialは各々のフックを呼ぶ前にメッセージを表示する．

%\subsection{Choosing how your hook should run}
\subsection{フックがの動作方法を選ぶ}
\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.

フックはシェルスクリプトのような通常のプログラムとして書くこともできるし，
Mercurialプロセスの内部で呼び出されるPython関数として書くこともできる．

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

フックを外部プログラムとして書く利点はMercurialの内部動作を知らなくてもフッ
クが書けることである．必要な追加の情報を得るために通常のMercurialコマンド
を呼び出すことができる．外部フックはプロセス内フックよりも低速なのがトレー
ドオフである．

%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プロセス内フックはMercurial APIへの完全なアクセスが可能である．
他のプロセスを生成することがないため，本質的に外部フックよりも高速である．
フックが必要とする情報の大半は，Mercurialコマンドを実行するよりも
Mercurial APIを使って集める方が容易い．

%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を使い慣れていたり，高い性能が必要ならば，フックをPythonで書くのが
よいだろう．しかし書こうとするのが単純明解なフックで，（多くのフックがそ
うであるように）性能には特に関心がない場合，シェルスクリプトとして書いて
も全く問題ない．

%\subsection{Hook parameters}
\subsection{フックパラメータ}
\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は各々のフックの呼出しの際にきちんと定義されたパラメータを渡
す．Pythonではパラメータはキーワード引数としてフック関数に渡される．外部
プログラムには，パラメータは環境変数として渡される．

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

フックがPythonで書かれているか，シェルスクリプトして書かれているかに関わ
らず，フック固有のパラメータ名と値は同じものが用いられる．ブール型パラメー
タはPythonではブール値として扱われるが，外部フックのための環境変数で
は，1（``真''）または0（``偽''）という数値として扱われる．
フックパラメータに\texttt{foo}という名前が付けられているとき，Pythonフッ
クへのキーワード引数も同じ\texttt{foo}という名前になる．
一方，外部フックのための環境変数では\texttt{HG\_FOO}という名前になる．

%\subsection{Hook return values and activity control}
\subsection{フックの戻り値と動作の制御}

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

正しく動作した外部フックはステータスとしてゼロを，プロセス内フックの場合
はブール値``false''を返さなければならない．なんらかの失敗があった場合は，
外部フックは非ゼロの終了ステータスを，プロセス内フックはブール値``true''
を返す．もしプロセス内フックが例外を発生した場合は，フックは失敗したと見
なされる．

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

動作の継続を制御するフックの場合は，ゼロ／falseは継続の許可を，非ゼ
ロ／true／例外の場合は禁止を意味する．

%\subsection{Writing an external hook}
\subsection{外部フックを作成する}

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

外部フックを \hgrc\ で定義し，実行する場合，フックはシェルに渡される値を
変換すため，フックの本体部分でシェルスクリプトを記述することができる．

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

外部フックは常にリポジトリのルートディレクトリをカレントディレクトリとし
て実行される．

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

各々のフックパラメータは環境変数として渡される．すなわち，名前は全て大文
字になり，``\texttt{HG\_}''という接頭辞が付けられる．

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

フックパラメータを例外として，Mercurialはフックを実行する際に環境変数の定
義や変更を行わない．多くのユーザが実行するサイトワイドのフックを作成する
場合，ユーザが設定している環境変数は異なることを記憶しておくべきである．
マルチユーザ環境の場合，フックを試す際にあなたが設定している環境変数に依
存すべきではない．

%\subsection{Telling Mercurial to use an in-process hook}
\subsection{Mercurialにプロセス内フックを使うように指示する}

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

プロセスないフックを定義する \hgrc\ 構文は実行可能フックとは僅かに異なっ
ている．フックの値は必ず``\texttt{python:}''で始まり，後にフック値として
用いられる呼出し可能オブジェクトの完全な名前が続かなければならない．

%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''.

フックが含まれるモジュールはフックが実行される時に自動的に読み込まれる．
モジュール名および\envar{PYTHONPATH}が正しいかぎり必ず動作するはずである．

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

今説明した構文と概念を説明する断片的な例を以下の\hgrc\ に示す．
\begin{codesample2}
  [hooks]
  commit.example = python:mymodule.submodule.myhook
\end{codesample2}
Mercurialが\texttt{commit.example}フックを実行する時，
\texttt{mymodule.submodule}を読み込み，呼出し可能オブジェクト
\texttt{myhook}を探し，実行する．

%\subsection{Writing an in-process hook}
\subsection{プロセス内フックを作成する}

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

実際には何も行わない最も単純なプロセス内フックをフックAPIの基本的な使い方
を説明するために示す．
\begin{codesample2}
  def myhook(ui, repo, **kwargs):
      pass
\end{codesample2}
Pythonフックへの最初の引数は常に\pymodclass{mercurial.ui}{ui}オブジェクト
である．2番目の引数はリポジトリオブジェクトで，現在のところ常に
\pymodclass{mercurial.localrepo}{localrepository}のインスタンスである．他
のキーワード引数はこれらの2つの引数に続く．これらは呼び出されているフック
に依存するが，フックはキーワードの辞書に\texttt{**kwargs}と記述すること
で，必要のない引数を無視することもできる．

%\section{Some hook examples}
\section{フックの例}

%\subsection{Writing meaningful commit messages}
\subsection{意味のあるコミットメッセージを出力する}

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

非常に短いコミットメッセージが有用であることはまずない．
図~\ref{ex:hook:msglen.go}に示す\hook{pretxncommit}という単純なフックは10
バイト以下の長さのコミットメッセージでコミットを行うことを禁止する．

\begin{figure}[ht]
  \interaction{hook.msglen.go}
%  \caption{A hook that forbids overly short commit messages}
  \caption{極端に短いコミットメッセージを禁止するフック}
  \label{ex:hook:msglen.go}
\end{figure}

%\subsection{Checking for trailing whitespace}
\subsection{ぶら下がった空白をチェックする}

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

コミットに関連したフックの興味深い使用法の一つにより奇麗なコードを書く手
助けがある． ``奇麗なコード''のごく単純な例は，例えば，新たなぶら下がった
空白を含む行を含まないものである．ぶら下がった空白とは，行末の一連のスペー
スやタブである．ほとんどの場合，ぶら下がった空白は不必要な見えないノイズ
であるが，問題を引き起こす場合もあり，除去したがる人が多い．

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

ぶら下がり空白の問題を直すために\hook{precommit}フックや
\hook{pretxncommit}フックを用いることができる．\hook{precommit}フックを使
う場合，どのファイルをコミットするのかフックは知ることがない．そのため，
リポジトリで変更されたファイルすべてについてぶら下がり空白をチェックする
必要がある． \filename{foo}というファイルをコミットしたい
が，\filename{bar}ファイルがぶら下がり空白を含んでいる場
合，\hook{precommit}フックでチェックを行うと，ファイル\filename{bar}の問
題のために\filename{foo}のコミットができなくなる．これは正しい挙動とは言
えない．

%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}フックを選び，チェックがコミット完了トランザクションの
直前まで起きないようにすべきである．これにより，コミットされようとするファ
イルだけをチェックすることができるようになる．しかしながら，コミットメッ
セージを対話的に入力し，コミットが失敗するとトランザクションはロールバッ
クするため，ぶら下がり空白を修正し，\hgcmd{commit}を再び実行し，コミット
する際にコミットメッセージを再入力しなければならない．

\begin{figure}[ht]
  \interaction{hook.ws.simple}
%  \caption{A simple hook that checks for trailing whitespace}
 \caption{ぶら下がった空白をチェックする単純なフック}
  \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.

図~\ref{ex:hook:ws.simple}は\hook{pretxncommit}というぶら下がり空白をチェッ
クする単純なフックを導入している．このフックは短いが，それほど有用ではな
い．更新がぶら下がり空白を含む行をどのファイルに追加しても，このフックは
エラーステータスと共に終了するが，問題のあるファイルや行を特定するための
情報は一切表示しない．このフックは変更のない行には全く関心を持たないとい
う良い性質も持っている．新規にぶら下がり空白を加える問題のある行のみを検
査する．

\begin{figure}[ht]
  \interaction{hook.ws.better}
%  \caption{A better trailing whitespace hook}
  \caption{ぶら下がり空白をチェックするフックの改良版}
  \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.

図~\ref{ex:hook:ws.better}はかなり複雑だが，より有用である．このフックは統
合形式のdiffをパースし，ぶら下がり空白を含むラインを探す．そして見つける
とファイル名と行番号を表示する．さらに変更がぶら下がり空白を追加すると，
このフックはコミットコメントを保存し，終了前に保存ファイルの名前を表示す
る．そしてMercurialにトランザクションをロールバックすることを指示する．問
題を修正した後で保存されたコミットメッセージを使うには
\hgcmdargs{commit}{\hgopt{commit}{-l}~\emph{filename}}とすればよい．

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

最後に，図~\ref{ex:hook:ws.better}のようにファイルからぶら下がり空白を除去
するために\command{perl}コマンドのインプレイス編集機能を用いる．これはこ
こで再現するに当たって十分短くかつ有効である．

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

%\section{Bundled hooks}
\section{組み合わせフック}

%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にはいくつかのフックが同梱されている．フックはMercurialソースツ
リーの\dirname{hgext}ディレクトリにある． Mercurialのバイナリパッケージを
使用しているのであれば，フックはパッケージインストーラがMercurialをインス
トールしたディレクトリ内の\dirname{hgext}ディレクトリにあるはずだ．

%\subsection{\hgext{acl}---access control for parts of a repository}
\subsection{\hgext{acl}---リポジトリの部分に対するアクセスコントロール}

%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}エクステンションは，リモートユーザにチェンジセットをネットワー
ク接続されたサーバにプッシュできるようにする．特定のリモートユーザが保護
された以外の部分の変更をプッシュできるようにリポジトリの任意の部分（全体
をも含む）を保護することができる．

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

このエクステンションはユーザがプッシュを行う際に，誰がチェンジセットをコ
ミット\emph{できない}ようにすることでアクセスコントロールを実装している．
このフックは，リモートユーザの認証を行う保護されたサーバ環境で，指定され
たユーザだけが変更をサーバにプッシュできるようにしたい場合にのみ意味をな
す．

%\subsubsection{Configuring the \hook{acl} hook}
\subsubsection{\hook{acl}フックの設定}

%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}フックを，到着するチェンジセットを管理するために使うためには，
\hook{pretxnchangegroup}フックとして用いる必要がある．このフックは，各々
のチェンジセットでどのファイルが変更されたのかをチェックし，変更禁止のファ
イルへ変更があった場合はチェンジセットをロールバックする．例：
\begin{codesample2}
  [hooks]
  pretxnchangegroup.acl = python:hgext.acl.hook
\end{codesample2}

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

\hgext{acl}エクステンションは3つのセクションで設定される．

%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}セクションは，\rcitem{acl}{sources}というエントリ1つを持
つ．このエントリでフックが監視すべき到着チェンジセット内ソース
を列挙する．
\begin{itemize}
\item[\rcitem{acl}{serve}] リモートリポジトリからhttpまたはsshを使って到
	     着するチェンジセットを制御する．\rcitem{acl}{sources}のデフォ
	     ルト値で，通常はこの設定内で唯一設定する必要のある項目であ
	     る．
\item[\rcitem{acl}{pull}] ローカルリポジトリからpullしたチェンジセットを
	     制御する．
\item[\rcitem{acl}{push}] ローカルリポジトリからpushしたチェンジセットを
	     制御する．
\item[\rcitem{acl}{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).

\rcsection{acl.allow}セクションはチェンジセットのリポジトリへの追加を許
可されているユーザを設定する．このセクションが存在しない場合，明示的に拒
否されていないすべてのユーザは許可される．このセクションが存在する場合，
明示的に許可されていないすべてのユーザは拒否される．（すなわち，空のセク
ションはすべてのユーザの拒否という意味になる．）

%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}セクションは，リポジトリへのチェンジセット追加を拒否
するユーザを設定する．このセクションが存在しないか，空の場合はどのユーザ
も拒否されない．

%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}と\rcsection{acl.deny}セクションの構文は同一である．
各々のエントリの左辺はファイルまたはディレクトリにマッチするglobパターン
で，リポジトリルートからの相対パスである．右辺はユーザ名である．

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

以下の例では，\texttt{docwriter}というユーザは，リポジトリの
\dirname{docs}サブツリーにしかpushできない．また\texttt{intern}は
\dirname{source/sensitive}以外ならばどのディレクトリのどのファイルにも変
更をpushすることができる．
\begin{codesample2}
  [acl.allow]
  docs/** = docwriter

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

%\subsubsection{Testing and troubleshooting}
\subsubsection{テストと問題解決}

%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}フックをテストしたい場合は，Mercurialのデバッグ出力を有効にし
て実行すると良い．サーバ上で実行するのであれば、\hggopt{--debug}オプショ
ンを渡すのは不便であったり、不可能であったりすることがある。このため、デ
バッグ出力は \hgrc でえも有効にできることを記憶しておくべきである．
\begin{codesample2}
  [ui]
  debug = true
\end{codesample2}
デバッグ出力が有効の場合，\hgext{acl}フックは，特定のユーザを許可あるい
は拒否した理由を知るのに十分な情報を出力する．

%\subsection{\hgext{bugzilla}---integration with Bugzilla}
\subsection{\hgext{bugzilla}---Bugzillaとの結合}

%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}エクステンションは，Bugzillaで管理されているバグへ，コミッ
トコメントの中でバグIDを参照している場合コメントを追加する．
このフックは共有サーバにもインストールできるので，リモートユーザが
変更をpushした場合にも動作する．

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

このフックは次のようにバグへコメントを追加する．（コメントの内容は設定可
能である．これについては下記を参照．）
\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}
このフックは，チェンジセットがバグを参照した場合，バグの更新を自動化でき
るところに価値がある．このフックをきちんと設定すれば，Bugzillaバグを閲覧
しているユーザが，バグから直ちに関係するチェンジセットを参照できるように
なる．

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

このフックのコードを出発点として，別のBugzillaとの結合を行うことも可能
である．いくつかの例を挙げる：
\begin{itemize}
 \item サーバにプッシュされたチェンジセットすべてにコミットコメントに有効
       なバグIDがあることを要求する．この場合，フックを
       \hook{pretxncommit}フックとして設定する必要がある．これによって，
       バグIDを含まない変更を拒否することができる．
 \item 到着するチェンジセットに，コメント追加に加えて，バグの\emph{ステー
       ト}を自動的に変更するようにできる．例えば，フックが``fixed bug
       31337''のような文字列を認識して，bug 31337のステートを``requires
       testing''に変更するなどが考えられる．
\end{itemize}

%\subsubsection{Configuring the \hook{bugzilla} hook}
\subsubsection{\hook{bugzilla}フックの設定}
\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}

このフックは次の例のようにサーバ上の\hgrc\ で\hook{incoming}フックと設定
すべきである．
\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.

このフックの特別な性質，Bugzillaがこのような結合を念頭に書かれていないこ
とによって，このフックの設定は複雑なプロセスとなる．

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

設定を開始する前に，フックを実行するホスト上でPython用のMySQLバインディン
グをインストールする必要がある．実行環境用にバイナリパッケージが用意され
ていなければ，ソースファイルを\cite{web:mysql-python}からダウンロードする
ことができる．

%Configuration information for this hook lives in the
%\rcsection{bugzilla} section of your \hgrc.
このフックの設定情報は，\hgrc ファイルの\rcsection{bugzilla}セクションに
ある．
\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}] サーバへインストールされたBugzillaのバー
	      ジョン．Bugzillaの使用するデータベースのスキーマは時に変更
	      されるため，フックはどのスキーマが使用されるのかを知る必要
	      がある．現時点ではBugzilla\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}{host}] Bugzillaデータを格納しているMySQLサーバの
	      ホストネーム．データベースは\hook{bugzilla}フックを実行す
	      るホストから接続可能に設定されていなければならない．

%\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サーバに接続するユーザ名．データベー
	      スは\hook{bugzilla}フックを実行するホスト上からこのユーザの
	      接続を許可するように設定されていなければならない．このユー
	      ザはBugzillaテーブルにアクセスし，変更できる権限がなければ
	      ならない．この項目のデフォルト値はMySQLデータベースでの
	      Bugzillaユーザの標準名\texttt{bugs}である．

%\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}] 上記のユーザのMySQLパスワード．平文で
	      保存されるため，権限のないユーザがこの\hgrc\ ファイルを確実
	      に読めないようにしておく必要がある．

%\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サーバ上のBugzillaデータベースの名前．
	      この項目のデフォルト値は\texttt{bugs}この項目のデフォルト値
	      はBugzillaがデータを保存するMySQLデータベースの標準名
	      \texttt{bugs}である．

%\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}] フックからバグにコメントが追加された時，
	      Bugzillaから講読者に通知メール
	     が送られるようにしたい場合は，フックがデータベースを更新し
	     た場合は常にコマンドが実行されるように設定しなければならな
	     い．実行するコマンドは，Bugzillaをどこにインストールしたかに
	      依存する．Bugzillaを\dirname{/var/www/html/bugzilla}にイン
	     ストールした場合，典型的なコマンドは次のようになる：
  \begin{codesample4}
    cd /var/www/html/bugzilla && ./processmail %s nobody@nowhere.com
  \end{codesample4}
Bugzilla \texttt{processmail}プログラムはbug~ID (フックが
``\texttt{\%s}''をbug~IDに置換する．)とemailアドレスを取る．このプログラ
ムはまた実行されるディレクトリ内でいくつかのファイルへ書き込みを必要とす
る．Bugzillaとフックが同じマシン上にインストールされていない場合，
Bugzillaがインストールされたサーバ上で\texttt{processmail}を実行する方法
を見つける必要がある．
\end{itemize}

%\subsubsection{Mapping committer names to Bugzilla user names}
\subsubsection{コミット者の名前をBugzillaのユーザ名へマップする}

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

デフォルトでは\hgext{bugzilla}フックはバグを更新するBugzillaユーザ名とし
てチェンジセットのコミッタのemailアドレスを使おうとする．
この挙動が望ましくない場合は，\rcsection{usermap}セクションをせっていする
ことでコミッタのemailアドレスをBugzillaのユーザ名にマップすることができる．

%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}セクションの各々の項目は，左辺にemailアドレス，右辺に
Bugzillaユーザ名を持つ．
\begin{codesample2}
  [usermap]
  jane.user@example.com = jane
\end{codesample2}
\rcsection{usermap}データを通常の \hgrc ファイルに保存することも
\hgext{bugzilla}フックに外部の\filename{usermap}ファイルを読むように指示
することもできる．後者の場合，例えば\filename{usermap}データをユーザが変
更可能なリポジトリに置くことも可能である．これはユーザに
\rcitem{bugzilla}{usermap}エントリの管理を任せることになる．メインの
\hgrc\ ファイルは次のようになる．：
\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{バグに追加された文字列を設定する}

%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.
フックが追加するコメント文字列はMercurialテンプレートとして指定することが
できる．\hgrc のエントリ(\rcsection{bugzilla}セクションに含まれているもの
を含む)で挙動をコントロールできる．
%\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生成用の部分パス名を作るためにリポジトリのパス名
	     から取り除かれる先行要素の数．サーバ上の
	     \dirname{/home/hg/repos}にリポジトリ群があ
	     り，\dirname{/home/hg/repos/app/tests}というリポジトリを持っ
	     ている場合，\texttt{strip}を\texttt{4}にすると部分パス名
	     \dirname{app/tests}が得られる．フックはこの部分パスをテンプ
	     レートの\texttt{webroot}に適用する．

\item[\texttt{template}] テンプレートに使用されるテキスト．通常のチェンジ
	     セット関連の変数に加えて，\texttt{hgweb}（上記の
	     \texttt{hgweb}の設定値）と\texttt{webroot}（上記の
	     \texttt{strip}を使って作ったパス）が利用できる.
\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:
さらに，\rcitem{web}{baseurl}項目を\hgrc の\rcsection{web}セクションに追
加できる．これはテンプレートの拡張時に\hgext{bugzilla}フックにより
Bugzillaコメントからチェンジセットを参照する際のURL生成のベース文字列とし
て利用される．

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

%Here is an example set of \hgext{bugzilla} hook config information.
\hgext{bugzilla}フックの設定情報の例を示す．
\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{テストと問題解決}

%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}フックを設定する際にBugzillaの\filename{processmail}スク
リプトの実行とコミッター名のユーザ名へのマッピングがよく問題になる．

%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}節で，サーバ上でMercurialを動作させているユー
ザと\filename{processmail}スクリプトを動かしているユーザが同じだと述べた．
\filename{processmail}スクリプトはBugzillaに設定ディレクトリ内のファイル
に書き込ませることがある． Bugzillaの設定ファイルは通常，ウェブサーバを起
動しているユーザの所有である．

%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}コマンドを使うことで\filename{processmail}を適切なユーザの
権限で実行することができる．\filename{sudoers}ファイルの記述例を示す．
\begin{codesample2}
  hg_user = (httpd_user) NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s
\end{codesample2}
この例では，ユーザ\texttt{hg\_user}が\filename{processmail-wrapper}プログ
ラムをユーザ\texttt{httpd\_user}の権限の元で実行することができる．

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

このラッパースクリプトから実行する間接実行は必要であ
る．\filename{processmail}はBugzillaをどこにインストールしてもカレントディ
レクトリから実行されるためである．実行制限の種類を\filename{sudoers}ファ
イルに記述する．ラッパースクリプトの内容はシンプルなものである．
\begin{codesample2}
  #!/bin/sh
  cd `dirname $0` && ./processmail "$1" nobody@example.com
\end{codesample2}
\filename{processmail}に渡すemailアドレスはどんなものでもよい．

%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}が正しく設定されていない場合，変更をサーバにプッシュす
る際に\hgext{bugzilla}フックからのエラーメッセージがユーザに送られる．
エラーメッセージは
\begin{codesample2}
  cannot find bugzilla user id for john.q.public@example.com
\end{codesample2}
のような内容である．これは，コミッタのアドレス
\texttt{john.q.public@example.com}が有効なBugzillaユーザネームでなく，ま
た有効なBugzillaユーザ名へのマップファイルである\rcsection{usermap}にも
記述がないという意味である．

%\subsection{\hgext{notify}---send email notifications}
\subsection{\hgext{notify}---メールで通知を行う}

%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の組み込みウェブサーバは全てのリポジトリの変更のRSSフィードを提
供するが，変更の通知をメールで受け取ることを好むユーザも多い．\hgext{notify}
\hgext{notify}フックは，チェンジセットが到着した時に関心を持つユーザのメー
ルアドレスに通知を送る．

%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}と同様に\hgext{notify}フックもテンプレートを使って送信さ
れる通知メッセージの内容をカスタマイズすることができる．

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

デフォルトでは\hgext{notify}フックは送信される全てのチェンジセットのdiff
を含む．このdiffのサイズの上限を設定したり，送信自体を停止することができ
る．diffを送信すると，講読者がURLをクリックすることなく変更をすぐにレビュー
できる利点がある．

%\subsubsection{Configuring the \hgext{notify} hook}
\subsubsection{\hgext{notify}フックの設定}

%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}フックを設定し，到着したチェンジセット毎や（一度のpullや
pushで到着した）一連のチェンジセット毎にemailを送信することができ
る．
\begin{codesample2}
  [hooks]
  # 一連の変更毎にメールを送信する
  changegroup.notify = python:hgext.notify.hook
  # 変更一つ毎にメールを送信する
  incoming.notify = python:hgext.notify.hook
\end{codesample2}

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

このフックの設定は\hgrc\ ファイルの\rcsection{notify}セクションに書く．
\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}] デフォルトではこのフックはメールを全く送信し
	     ない．その代わり，送信されのと同じ内容を表示する．この項目を
	     \texttt{false}に設定するとメールが送信される．デフォルトでメー
	     ル送信がオフにされている理由は，意図する通りにこの設定を行う
	     ためには数回の試行が必要なためである．デバッグ中に講読者に壊
	     れた通知を送るのはスパムまがいで好ましくない．

%\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}] 講読者情報を含む設定ファイルへのパス．メイ
	     ンの\hgrc\ と分離することで，リポジトリ毎にリポジトリ内で管
	     理できる．協力者はリポジトリをクローンし，講読者をアップデー
	     トして変更をサーバにpushできる．

%\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}] リポジトリに講読者がいるかどうか判定する際
	     に，リポジトリのパスから除去する先行部分をパス区切り文字で示
	     した数．例えば，サーバでリポジトリ群が
	     \dirname{/home/hg/repos}に置かれており， \hgext{notify}が
	     \dirname{/home/hg/repos/shared/test}というリポジトリを対象と
	     する時，\rcitem{notify}{strip} を \texttt{4}に設定すると
	     \hgext{notify}はパスを\dirname{shared/test}に短縮し，これを
	     用いて講読者のマッチを行う．

%\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}] メッセージを送信する時に使われるテキス
	     トのテンプレート．メッセージのヘッダとボディ両方を設定する
	     ことができる．

%\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}] メッセージの末尾に添付されるdiffデータの
	     最大行数．diffがこの値より大きい場合は切り詰められる．デフォ
	     ルトでは300行．この値を\texttt{0}にすることで通知emailへの
	     diffの添付を抑制することができる．

%\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}] 対象チェンジセットのソースのリスト．例え
	     ば，このリストでリモートユーザがサーバ経由でリポジトリへプッ
	     シュした変更に関してのみ通知を行うように制限することができ
	     る．ここで指定できるソースについては\ref{sec:hook:sources}
	     節を参照のこと．
\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}セクションの\rcitem{web}{baseurl}項目を設定しているなら，
これを\texttt{webroot}としてテンプレート内で使うことができる．

%Here is an example set of \hgext{notify} configuration information.
\hgext{notify}設定の例を示す．
%\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]
  # 実際にメールを送信するか
  test = false
  # 講読者データが通知リポジトリ内にある
  config = /home/hg/repos/notify/notify.conf
  # リポジトリ群はサーバの /home/hg/repos にあるので 4つの "/" 文字をストリップする
  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:
生成されるメッセージは次のようになる：
\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{テストと問題解決}

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

デフォルトでは\hgext{notify}エクステンションは\emph{メールを送信しない}こ
とに留意すること．実際に送信させるためには明示的に\rcitem{notify}{test}を
\texttt{false}に設定しなければならない．この設定をしなければ，送信するの
と同じメッセージを表示するだけである．

%\section{Information for writers of hooks}
\section{フック作製者への情報}
\label{sec:hook:ref}

%\subsection{In-process hook execution}
\subsection{プロセス内フックの実行}

%An in-process hook is called with arguments of the following form:
プロセス内フックは次のような形式の引数を伴って呼び出される：
\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}パラメータは\pymodclass{mercurial.ui}{ui}のオブジェクトである．
\texttt{repo}パラメータは
\pymodclass{mercurial.localrepo}{localrepository}のオブジェクトである．
\texttt{**kwargs}パラメータの名前と値は，呼び出されるフックに依存し，次
のような共通した特徴を持つ．
%\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 パラメータが\texttt{node}または\texttt{parent\emph{N}}と名付けられ
      た場合，16進数のチェンジセットIDを持つ． ``ヌルチェンジセットID''を
      表すために0ではなく空の文字列が用いられる．
\item パラメータが\texttt{url}と名付けられた場合，リモートリポジトリが特
      定されるならばそのURLを持つ．
\item ブール値を持つパラメータはPythonの\texttt{bool}オブジェクトとして
      表現される．
\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.

プロセス内フックは，リポジトリのルートで実行される外部フックと異なりプロ
セスのワーキングディレクトリの変更なしに呼び出される．プロセス内フックは
プロセスワーキングディレクトリを変更してはならない．さもなけれ
ば，Mercurial APIへの呼び出しは全て失敗する．

%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''.

フックがブール値``false''を返した場合，フックの実行は成功したと見なされ
る．ブール値``true''を返した場合および例外を発生させた場合は失敗したと見
なされる．呼び出し既約は ``失敗した時は教える''と覚えるとよい．

%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フックに渡されるチェンジセットIDは，Mercurial APIが通常用いるバイナ
リハッシュ値ではなく16進数文字列であることに注意．ハッシュ値を16進数文字
列からバイナリに変換するには\pymodfunc{mercurial.node}{bin}関数を用いる．

%\subsection{External hook execution}
\subsection{フックの外部実行}

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

外部フックはMercurialを実行しているシェルで実行される．変数の置換やコマン
ドのリダイレクトなどのシェルの機能が利用できる．外部フックは，Mercurialの
実行と同じディレクトリ内で実行されるプロセス内フックとは異なり，リポジト
リのルートディレクトリで実行される．

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

フックパラメータはフックに環境篇ストして渡される．各々の環境変数名は大文
字に変換され，接頭辞``\texttt{HG\_}''が付けられる．例えば
``\texttt{node}''というパラメータが使われたとすると，このパラメータを表
す環境変数名は``\texttt{HG\_NODE}''となる．

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

ブール値パラメータについては，真が``\texttt{1}''，偽が``\texttt{0}''と表
現される．\envar{HG\_NODE}，\envar{HG\_PARENT1}，\envar{HG\_PARENT2}とい
う環境変数が定義されているとき，これらは16進数の文字列で表されたチェンジ
セットIDを含む．``ヌルチェンジセットID''を表現するためにゼロでなく空の文
字列が用いられる．環境変数が\envar{HG\_URL}であるとき，リモートリポジトリ
が特定できれば，そのURLが入る．

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

フックがステータス0で終了した場合は成功と見なされる．0以外のステータスで
終了した場合は実行が失敗したと見なされる．

%\subsection{Finding out where changesets come from}
\subsection{チェンジセットのソースを調べる}

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

ローカルなリポジトリ・他のリポジトリ間のチェンジセットの転送に関連したフッ
クは，遠隔地の情報を得ることができる．Mercurialは\emph{どのように}変更が
転送されるか，また多くの場合\emph{どこへ}，あるいは\emph{どこから}転送さ
れるのかも知ることができる．

%\subsubsection{Sources of changesets}
\subsubsection{チェンジセットのソース}
\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はフックにチェンジセットの内容，リポジトリ間の転送方法などを通知
する． Mercurialは通知のために\texttt{source}というPythonパラメータまたは
\envar{HG\_SOURCE}という環境変数を用いる．

%\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}] チェンジセットはリモートリポジトリからhttpまたは
	     sshで転送された．
\item[\texttt{pull}] チェンジセットは2つのリポジトリ間をpullによって転送
	     された．
\item[\texttt{push}] チェンジセットは2つのリポジトリ間をpushによって転送
	     された．
\item[\texttt{bundle}] チェンジセットはバンドルによって転送された．
\end{itemize}

%\subsubsection{Where changes are going---remote repository URLs}
\subsubsection{変更の行き先---リモートリポジトリのURL}
\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は，可能であるならばリポジトリ間のチェンジセットデータの転送の相
手の情報をフックに通知する． Mercurialは\texttt{url}というPythonパラメー
タまたは\envar{HG\_URL}という環境変数を使って通知を行う．

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

この情報はいつも既知である．httpまたはsshでサービスされているリポジトリか
らフックが起動された場合，Mercurialはリモートリポジトリがどこにあるのかを
通知することはできないが，クライアントがどこから接続しているのかは知るこ
とができる．

その場合，URLは次のいずれかの形式を取る：
\begin{itemize}
\item \texttt{remote:ssh:\emph{ip-address}}---あるIPアドレス上のリモート
      sshクライアント
\item \texttt{remote:http:\emph{ip-address}}---あるIPアドレス上のhttpク
      ライアント．もしクライアントがSSLを使用している場
      合，\texttt{remote:https:\emph{ip-address}}のような形式になる．
\item Empty---リモートクライアントに関する情報がない．
\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}}---与えられたIPアドレスのリモー
      トsshクライアント．
\item \texttt{remote:http:\emph{ip-address}}---与えられたIPアドレスのリモー
      トhttpクライアント．クライアントがSSLを使っている場合は
      \texttt{remote:https:\emph{ip-address}}の形式になる．
\item 空白---リモートクライアントについての情報は得られなかった．
\end{itemize}

%\section{Hook reference}
\section{フック参照}

%\subsection{\hook{changegroup}---after remote changesets added}
\subsection{\hook{changegroup}---リモートチェンジセットが追加された後}
\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.

このフックは，\hgcmd{pull}または\hgcmd{unbundle}などで既存のチェンジセッ
トグループがリポジトリに追加された後に実行される．このフックは，1つ以上の
チェンジセットを追加するオペレーションにつき一度実行される．グループに関
係なくチェンジセット1つ毎に実行される\hook{incoming}フックとは対照的であ
る．

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

このフックを使って追加されたチェンジセットに対する自動ビルドやテストを起
動することや，新たな変更を持つリポジトリの講読者に通知することができる．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{node}] チェンジセットID．追加されたグループの最初のチェンジ
	     セットのID．このIDを含み
	     \index{tags!\texttt{tip}}\texttt{tip}までの間のチェンジセッ
	     ト全ては一回の\hgcmd{pull}，\hgcmd{push}または
	     \hgcmd{unbundle}で追加された．
\item[\texttt{source}] 文字列．これらの変更のソース．詳細については
	     \ref{sec:hook:sources}を参照のこと．
\item[\texttt{url}] URL．リモートリポジトリが特定できる場合はそのアドレ
	     ス．詳細については\ref{sec:hook:url}を参照のこと．
\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})

参考：\hook{incoming} (\ref{sec:hook:incoming}節), \hook{prechangegroup}
(\ref{sec:hook:prechangegroup}節), \hook{pretxnchangegroup}
(\ref{sec:hook:pretxnchangegroup}節)

%\subsection{\hook{commit}---after a new changeset is created}
\subsection{\hook{commit}---新しいチェンジセットが作成された後}
\label{sec:hook:commit}

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

このフックは新たなチェンジセットが作られた後に呼ばれる．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{node}] チェンジセットID．新たにコミットされたチェンジセッ
	     トのID．
\item[\texttt{parent1}] チェンジセットID．新たにコミットされたチェンジセッ
	     トの1つ目の親のチェンジセットID.
\item[\texttt{parent2}] チェンジセットID．新たにコミットされたチェンジセッ
	     トの2つ目の親のチェンジセットID.
\end{itemize}

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

参考：\hook{precommit} (\ref{sec:hook:precommit}節), \hook{pretxncommit}
(\ref{sec:hook:pretxncommit}節)


%\subsection{\hook{incoming}---after one remote changeset is added}
\subsection{\hook{incoming}---リモートチェンジセットが追加された後}
\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.

このフックは\hgcmd{push}コマンドなどで既存のチェンジセットがリポジトリに
追加された後で実行される．チェンジセットのグループが一度に追加された場
合，各々のチェンジセットについて一度ずつこのフックが呼び出される．

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

このフックは\hook{changegroup}(\ref{sec:hook:changegroup}節)と同じ目的で
使うことができる．違いは\hook{changegroup}がチェンジセットグループ全体に
対して一度呼ばれる点である．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{node}] チェンジセットID．新たに追加されるチェンジセットの
	     ID．
\item[\texttt{source}] 文字列．これらの変更のソース．詳細については
	     \ref{sec:hook:sources}を参照のこと．
\item[\texttt{url}] URL．リモートリポジトリが特定できる場合にはそのアド
	     レス．詳細については\ref{sec:hook:url}を参照のこと．
\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})
参考：\hook{changegroup} (\ref{sec:hook:changegroup}節)
\hook{prechangegroup} (\ref{sec:hook:prechangegroup}節),
\hook{pretxnchangegroup} (\ref{sec:hook:pretxnchangegroup}節)

%\subsection{\hook{outgoing}---after changesets are propagated}
\subsection{\hook{outgoing}---チェンジセットが波及した後}
\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.

このフックはチェンジセットのグループが\hgcmd{push}や\hgcmd{bundle}コマン
ドなどによって外部に波及した後で実行される．

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

このフックを使って管理者はpullされた変更を知ることができる．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{node}] チェンジセットID．送信されたチェンジセットグループ
	     の最初のチェンジセットID.
\item[\texttt{source}] 文字列．操作元(~\ref{sec:hook:sources}節を参照)．
	     リモートクライアントが変更をリポジトリからpullすると
	     \texttt{source}が\texttt{serve}となる．リポジトリから変更を
	     入手したクライアントがローカルであれば，\texttt{source}はク
	     ライアントの行った動作に応じて
	     \texttt{bundle}，\texttt{pull}，\texttt{push}のいずれかとな
	     る．
\item[\texttt{url}] URL．リモートリポジトリが特定できる場合はそのアドレス．
	     詳細については\ref{sec:hook:url}節を参照のこと．
\end{itemize}


%See also: \hook{preoutgoing} (section~\ref{sec:hook:preoutgoing})
参考： \hook{preoutgoing} (\ref{sec:hook:preoutgoing}節)

%\subsection{\hook{prechangegroup}---before starting to add remote
%changesets}
\subsection{\hook{prechangegroup}---リモートチェンジセットがが追加される
  前}
\label{sec:hook:prechangegroup}

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

この制御フックはMercurialが一連のチェンジセットを別のリポジトリに追加す
る前に実行される．

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

このフックは追加されるチェンジセットの情報は何も持たない．なぜならこのフッ
クはチェンジセットの送信が始まる前に実行されるからだ．フックの実行が失敗
した場合はチェンジセットは送信されない．

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

このフックを使って，外部の変更がリポジトリについかされないようにすること
もできる．例えば，このフックをサーバで提供されるブランチを一時的または永
続的に``凍結''し，ローカルな管理者はリポジトリを変更できるが，リモート
ユーザはそのリポジトリにpushできないようにできる．

%Parameters to this hook:
このフックへのパラメータ：
\begin{itemize}
\item[\texttt{source}] 文字列．変更のソース．詳細については
	     \ref{sec:hook:sources}を参照．
\item[\texttt{url}] URL．リモートリポジトリが特定される場合はそのアドレ
	     ス．詳細については\ref{sec:hook:url}を参照．
\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})

参考： \hook{changegroup} (\ref{sec:hook:changegroup}節)，
\hook{incoming} (\ref{sec:hook:incoming}節)，
\hook{pretxnchangegroup} (\ref{sec:hook:pretxnchangegroup}節)

%\subsection{\hook{precommit}---before starting to commit a changeset}
\subsection{\hook{precommit}---チェンジセットをコミットする前}
\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.

このフックはMercurialが新しいチェンジセットをコミットする前に実行される．
実行はMercurialがコミットされるファイル名，コミットメッセージ，コミット日
時のようなコミットのためのメタデータを持つ前である．

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

このフックを使って，外部からのチェンジセットの取り込みを許可する一方で，
新しいチェンジセットをコミットできないようにすることもできる．また，ビル
ドやテストを実行したり，それが成功した時のみコミットを行うようにすること
もできる．

%Parameters to this hook:
このフックへのパラメータ：
%\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}] チェンジセットID．ワーキングディレクトリの1つ目の
	     親のチェンジセットID．
\item[\texttt{parent2}] チェンジセットID．ワーキングディレクトリの2つ目の
	     親のチェンジセットID．
\end{itemize}
%If the commit proceeds, the parents of the working directory will
%become the parents of the new changeset.

コミットが進行するとワーキングディレクトリの親は新しいチェンジセットの親
となる．

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

参考：\hook{commit} (\ref{sec:hook:commit}節)，\hook{pretxncommit}
(\ref{sec:hook:pretxncommit}節)

%\subsection{\hook{preoutgoing}---before starting to propagate
%changesets}
\subsection{\hook{preoutgoing}---チェンジセットを波及させる前に}
\label{sec:hook:preoutgoing}

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

このフックはMercurialが送信するチェンジセットを識別する前に実行される．

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

このフックを用いて，他のリポジトリへ変更を送信しないようにすることもでき
る．

%Parameters to this hook:
このフックへのパラメータ：
%\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}] 文字列．このリポジトリから変更を取得しようとする動
	     作のソース（\ref{sec:hook:sources}を参照）．このパラーメタが
	     取り得る値については， \ref{sec:hook:outgoing}節の
	     \hook{outgoing}フックへの\texttt{source}パラメータの項目を参
	     照のこと．
\item[\texttt{url}] URL．リモートリポジトリが特定できる場合はそのアドレ
	     ス．詳細については\ref{sec:hook:url}を参照のこと．
\end{itemize}

%See also: \hook{outgoing} (section~\ref{sec:hook:outgoing})
参考： \hook{outgoing} (\ref{sec:hook:outgoing}節)

%\subsection{\hook{pretag}---before tagging a changeset}
\subsection{\hook{pretag}---チェンジセットにタグをつける前に}
\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.

この制御フックはタグが作成される前に実行される．フックの実行が成功した場
合はタグが作成される．フックの実行が失敗した場合はタグは作成されない．

%Parameters to this hook:
このフックへのパラメータ：
%\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}] ブール値．新しいタグがリポジトリローカルなもの
	     (\sfilename{.hg/localtags}に保存される)かMercurialに管理
	     されるもの(\sfilename{.hgtags}に保存される)かを示す．
\item[\texttt{node}] チェンジセットID．タグ付けされるチェンジセットのID.
\item[\texttt{tag}] 文字列．生成されたタグの名前．
\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.

生成されたタグがリビジョンコントロールされている場合，\hook{precommit}フッ
クと\hook{pretxncommit}フック(\ref{sec:hook:commit}節および
\ref{sec:hook:pretxncommit})節)の両方が実行される．

%See also: \hook{tag} (section~\ref{sec:hook:tag})
参考： \hook{tag} (\ref{sec:hook:tag}節)

%\subsection{\hook{pretxnchangegroup}---before completing addition of
%remote changesets}
\subsection{\hook{pretxnchangegroup}---リモートチェンジセットの追加を完
  了する前に}
\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.

この制御フックは，外部から新しいチェンジセットを追加するトランザクション
が完了する前に実行される．フックの実行が成功した場合，トランザクションは
完了し，全てのチェンジセットはリポジトリ内で永続的になる．フックの実行が
失敗した場合，トランザクションはロールバックされ，チェンジセットのデータ
は消去される．

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

このフックはトランザクション中のチェンジセットのメタデータにアクセスする
ことができるが，このデータを使って永続的なことは一切してはならない．ワー
キングディレクトリの変更もしてはならない．

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

このフックの実行中，他のMercurialプロセスがリポジトリにアクセスすると，ト
ランザクション中のチェンジセットを永続的なものと見なす可能性がある．適切
な回避策を講じなければ，これが競合状態を引き起こす可能性がある．

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

このフックは一連のチェンジセットを自動的に排除するために使うこともでき
る．このフックの実行が失敗した場合，トランザクションがロールバックされる
時にチェンジセット全体がリジェクトされる．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{node}] チェンジセットID．追加される一連のチェンジセットの
	     うち，最初のチェンジセットID．これと
	     \index{tags!\texttt{tip}}\texttt{tip}の間の全てのチェンジセッ
	     トが一度の\hgcmd{pull}, \hgcmd{push} または
\item[\texttt{source}] 文字列．これらの変更のソース．詳細については
	     \ref{sec:hook:sources}節を参照のこと．
\item[\texttt{url}] URL．既知のリモートリポジトリの場所．詳細については
	     \ref{sec:hook:url}節を参照のこと．
\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})

参考： \hook{changegroup} (\ref{sec:hook:changegroup}節),
\hook{incoming} (\ref{sec:hook:incoming}節),
\hook{prechangegroup} (\ref{sec:hook:prechangegroup}節)

%\subsection{\hook{pretxncommit}---before completing commit of new
%changeset}
\subsection{\hook{pretxncommit}---新しいチェンジセットのコミットを完了す
  る前に}
\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.

この制御フックは新たなコミットのためのトランザクションの完了前に実行され
る．このフックの実行が成功した場合，トランザクションが完了され，チェンジ
セットはリポジトリ内で永続的になる．フックの実行が失敗した場合はトランザ
クションはロールバックされ，コミットデータは消去される．

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

このフックはトランザクション中のチェンジセットのメタデータにアクセスする
ことができるが，このデータを使って永続的なことは一切してはならない．ワー
キングディレクトリの変更もしてはならない．

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

このフックの実行中，他のMercurialプロセスがリポジトリにアクセスすると，ト
ランザクション中のチェンジセットを永続的なものと見なす可能性がある．適切
な回避策を講じなければ，これが競合状態を引き起こす可能性がある．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{node}] チェンジセットID．新たにこ見んとされたチェンジセッ
	     トのID．
\item[\texttt{parent1}] チェンジセットID．新たにコミットされたチェンジセッ
	     トの1つ目の親のチェンジセットID．
\item[\texttt{parent2}] チェンジセットID．新たにコミットされたチェンジセッ
	     トの2つ目の親のチェンジセットID．
\end{itemize}

%See also: \hook{precommit} (section~\ref{sec:hook:precommit})
参考：\hook{precommit} (\ref{sec:hook:precommit}節)

%\subsection{\hook{preupdate}---before updating or merging working
%directory}
\subsection{\hook{preupdate}---ワーキングディレクトリのアップデートまた
  はマージの前に}
\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.

この制御フックはワーキングディレクトリのアップデートまたはマージが始まる
前に実行される． Mercurialの通常のアップデート前チェックがアップデートま
たはマージを実行できると判断した場合にのみ実行される．フックの実行が成功
した場合，アップデートまたはマージが行われる．失敗した場合はアップデート
またはマージは開始されない．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{parent1}] チェンジセットID．ワーキングディレクトリがアップ
	     デートされる親ID.ワーキングディレクトリがマージされる場合，
	     親IDは変更されない．
\item[\texttt{parent2}] チェンジセットID．ワーキングディレクトリがマージ
	     される場合のみセットされる．ワーキングディレクトリがマージ
	     されるリビジョンID．
\end{itemize}

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

参考： \hook{update} (\ref{sec:hook:update}節)

%\subsection{\hook{tag}---after tagging a changeset}
\subsection{\hook{tag}---チェンジセットにタグ付けした後に}
\label{sec:hook:tag}

%This hook is run after a tag has been created.
このフックはタグが生成された後に実行される．

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

このフックへのパラメータ：
\begin{itemize}
\item[\texttt{local}] ブール値．新しいタグがリポジトリローカルなもの
	     (\sfilename{.hg/localtags}に保存される)かMercurialに管理
	     されるもの(\sfilename{.hgtags}に保存される)かを示す．
\item[\texttt{node}] チェンジセットID．タグ付けされるチェンジセットのID.
\item[\texttt{tag}] 文字列．生成されたタグの名前．
\end{itemize}

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

生成されたタグがリビジョンコントロールされている場合，\hook{commit}フッ
ク(\ref{sec:hook:commit}節)はこのフックの前に実行される．

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

参考： \hook{pretag} (\ref{sec:hook:pretag}節)

%\subsection{\hook{update}---after updating or merging working
%directory}
\subsection{\hook{update}---ワーキングディレクトリを更新またはマージした
  後に}
\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.

このフックはワーキングディレクトリのアップデートまたはマージが完了した後
に実行される．マージは失敗することもある（外部の\command{hgmerge}コマンド
はファイル内のコンフリクトを解決できないことがある）ので，このフックはアッ
プデートまたはマージが正常に完了したかどうかを問い合わせる．

%\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}] ブール値．アップデートまたはマージが正常に完了した
	     かどうかを示す．
\item[\texttt{parent1}] チェンジセットID．ワーキングディレクトリがアップ
	     デートされる親ID．ワーキングディレクトリがマージされる場合，親
	     IDは変化しない．xxx
\item[\texttt{parent2}] チェンジセットID．ワーキングディレクトリがマージ
	     される時のみセットされる．ワーキングディレクトリがマージされ
	     るリビジョンID．
\end{itemize}

%See also: \hook{preupdate} (section~\ref{sec:hook:preupdate})
参考: \hook{preupdate} (\ref{sec:hook:preupdate}節)

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