%\chapter{Adding functionality with extensions}
\chapter{拡張による機能の追加}
\label{chap:hgext}

%While the core of Mercurial is quite complete from a functionality
%standpoint, it's deliberately shorn of fancy features.  This approach
%of preserving simplicity keeps the software easy to deal with for both
%maintainers and users.

機能の観点から見るとMercurialはかなり完備しているが，派手な機能については
意図的に排除している．Mercurialのメンテナとユーザの双方にとって単純さを保
つためにこのアプローチを取っている．

%However, Mercurial doesn't box you in with an inflexible command set:
%you can add features to it as \emph{extensions} (sometimes known as
%\emph{plugins}).  We've already discussed a few of these extensions in
%earlier chapters.

しかしながら，Mercurialは融通の利かないコマンドセットを提供しているのでは
ない．\emph{extensions}（あるいは\emph{plugins}と呼ばれることもある）によっ
て機能を追加することができる．これらのいくつかについては，以前の章で見て
いる．

\begin{itemize}
%\item Section~\ref{sec:tour-merge:fetch} covers the \hgext{fetch}
%  extension; this combines pulling new changes and merging them with
%  local changes into a single command, \hgxcmd{fetch}{fetch}.
\item セクション\ref{sec:tour-merge:fetch}は\hgext{fetch}エクステンション
       をカバーしている．これは新しい変更をpullし，ローカルな変更とマージ
       を単一のコマンド\hgxcmd{fetch}{fetch}で実行する．
%\item In chapter~\ref{chap:hook}, we covered several extensions that
%  are useful for hook-related functionality: \hgext{acl} adds access
%  control lists; \hgext{bugzilla} adds integration with the Bugzilla
%  bug tracking system; and \hgext{notify} sends notification emails on
%  new changes.
\item \ref{chap:hook}では，フックに関連したいくつかの拡張について扱う．
\hgext{acl}はアクセス制御リストを追加する．\hgext{bugzilla}はBugzilla機能
の統合機能を提供する．\hgext{notify}は，新たな変更の際に通知電子メールを
送る機能を提供する．
%\item The Mercurial Queues patch management extension is so invaluable
%  that it merits two chapters and an appendix all to itself.
%  Chapter~\ref{chap:mq} covers the basics;
%  chapter~\ref{chap:mq-collab} discusses advanced topics; and
%  appendix~\ref{chap:mqref} goes into detail on each command.
\item Mercurial Queueというパッチマネージメント拡張は，非常に重要なので2
      章と付録1章を費やして説明する．
  Chapter~\ref{chap:mq}は基本的な機能を説明する．
  chapter~\ref{chap:mq-collab}では高度な機能について説明し，
  appendix~\ref{chap:mqref}では各コマンドの詳細を説明する．
\end{itemize}

%In this chapter, we'll cover some of the other extensions that are
%available for Mercurial, and briefly touch on some of the machinery
%you'll need to know about if you want to write an extension of your
%own.
この章ではMercurialで利用可能なその他の拡張について取り扱い，また自分で
Mercurial拡張を書く時に役立つ内部の機構についても説明する．
\begin{itemize}
%\item In section~\ref{sec:hgext:inotify}, we'll discuss the
%  possibility of \emph{huge} performance improvements using the
%  \hgext{inotify} extension.
\item \ref{sec:hgext:inotify}節では\hgext{inotify}拡張を用いることで得ら
      れる\emph{大きな}性能向上について述べる．
\end{itemize}

%\section{Improve performance with the \hgext{inotify} extension}
\section{\hgext{inotify}拡張による性能向上}
\label{sec:hgext:inotify}

%Are you interested in having some of the most common Mercurial
%operations run as much as a hundred times faster?  Read on!
Mercurialの最も多用されるコマンドのいくつかが数百倍速くなることに興味があ
るならばぜひ読んで欲しい！

%Mercurial has great performance under normal circumstances.  For
%example, when you run the \hgcmd{status} command, Mercurial has to
%scan almost every directory and file in your repository so that it can
%display file status.  Many other Mercurial commands need to do the
%same work behind the scenes; for example, the \hgcmd{diff} command
%uses the status machinery to avoid doing an expensive comparison
%operation on files that obviously haven't changed.

通常の条件下でMercurialは高い性能を持っているが， \hgcmd{status}コマンド
を実行した時，Mercurialはほぼ全てのディレクトリとファイルをスキャンするこ
とになる．他の多くのMercurialコマンドは，このような操作を意識させないよう
になっている．例えば\hgcmd{diff}はステータス機構を用いて，明らかに変更さ
れていないファイルの比較を避けている．

%Because obtaining file status is crucial to good performance, the
%authors of Mercurial have optimised this code to within an inch of its
%life.  However, there's no avoiding the fact that when you run
%\hgcmd{status}, Mercurial is going to have to perform at least one
%expensive system call for each managed file to determine whether it's
%changed since the last time Mercurial checked.  For a sufficiently
%large repository, this can take a long time.

良い性能を得るためには，ファイルステータスの取得が重要な関心事となるた
め，Mercurialの作者たちはこれをぎりぎりのところまで最適化している．しかし
\hgcmd{status}コマンドではこれを避ける手立てがない． Mercurialは，管理し
ているファイルが最後にチェックした時から変更されているか調べるために，少
なくとも一つの高価なシステムコールをする必要がある．ある程度以上大きなリ
ポジトリでは，この操作には長い時間を要する．

%To put a number on the magnitude of this effect, I created a
%repository containing 150,000 managed files.  I timed \hgcmd{status}
%as taking ten seconds to run, even when \emph{none} of those files had
%been modified.

この影響について調べるために150,000のファイルを擁するリポジトリを作成し
た．\emph{まったく}変更がない場合でも\hgcmd{status}コマンドの実行には10
秒を要した．

%Many modern operating systems contain a file notification facility.
%If a program signs up to an appropriate service, the operating system
%will notify it every time a file of interest is created, modified, or
%deleted.  On Linux systems, the kernel component that does this is
%called \texttt{inotify}.

近年のオペレーティングシステムは，ファイル通知の機構を備えている．プログ
ラムが適切なサービスに登録すると，オペレーティングシステムは対象となるファ
イルの作成，変更，削除をプログラムに通知する． Linuxシステムではこれを行
うカーネルコンポーネントは\texttt{inotify}と呼ばれる．

%Mercurial's \hgext{inotify} extension talks to the kernel's
%\texttt{inotify} component to optimise \hgcmd{status} commands.  The
%extension has two components.  A daemon sits in the background and
%receives notifications from the \texttt{inotify} subsystem.  It also
%listens for connections from a regular Mercurial command.  The
%extension modifies Mercurial's behaviour so that instead of scanning
%the filesystem, it queries the daemon.  Since the daemon has perfect
%information about the state of the repository, it can respond with a
%result instantaneously, avoiding the need to scan every directory and
%file in the repository.

Mercurialの\hgext{inotify}拡張は，\hgcmd{status}コマンドを最適化するため
に，カーネルの\texttt{inotify}コンポーネントへアクセスする．この拡張は2つ
のコンポーネントからなる． \texttt{inotify}サブシステムから通知を受け取る
ためのデーモンがバックグランドで動作する．このデーモンはMercurialの他のコ
マンドからの接続も受け付ける．この拡張はMercurialの挙動を変更し，ファイル
システムをスキャンするのではなく，デーモンへの問い合わせを行うようにす
る．デーモンはリポジトリの状態を完全に把握しているので，直ちに問い合わせ
に返答することができ，リポジトリのディレクトリとファイルのスキャンを避け
ることができる．

%Recall the ten seconds that I measured plain Mercurial as taking to
%run \hgcmd{status} on a 150,000 file repository.  With the
%\hgext{inotify} extension enabled, the time dropped to 0.1~seconds, a
%factor of \emph{one hundred} faster.

プレーンなMercurialでは\hgcmd{status}コマンドが150,000ファイルのリポジト
リに対して10秒を要していたことを思い出して欲しい。
\hgext{inotify}拡張を使った場合、所要時間は0.1秒に下がり，\emph{100}倍速
くなっていることが分かる．

%Before we continue, please pay attention to some caveats.
さらに進む前に，注意点を挙げる．
\begin{itemize}
%\item The \hgext{inotify} extension is Linux-specific.  Because it
%  interfaces directly to the Linux kernel's \texttt{inotify}
%  subsystem, it does not work on other operating systems.
 \item \hgext{inotify}拡張はLinux特有のものである．この機能拡張はLinuxの
       \texttt{inotify}サブシステムに直接アクセスするため，他のオペレー
       ティングシステムでは動作しない．

%\item It should work on any Linux distribution that was released after
%  early~2005.  Older distributions are likely to have a kernel that
%  lacks \texttt{inotify}, or a version of \texttt{glibc} that does not
%  have the necessary interfacing support.
 \item 2005年初め以降にリリースされたどのようなLinuxディストリビューショ
       ンでも動作するはずだが，古いディストリビューションでは
       \texttt{inotify}を欠いていたり，必要なインターフェースサポートを
       \texttt{glibc}が提供していなかったりする可能性がある．

%\item Not all filesystems are suitable for use with the
%  \hgext{inotify} extension.  Network filesystems such as NFS are a
%  non-starter, for example, particularly if you're running Mercurial

%  on several systems, all mounting the same network filesystem.  The
%  kernel's \texttt{inotify} system has no way of knowing about changes
%  made on another system.  Most local filesystems (e.g.~ext3, XFS,
%  ReiserFS) should work fine.
 \item 全てのファイルシステムが\hgext{inotify}拡張で利用可能なわけではな
       い．例え
ばMercurialをいくつかのシステムで動作させている場合，同一のネットワークファ
イルシステムを各々のシステムでマウントしていることが多いが， NFSなどのネッ
トワークファイルシステムは考慮されていない．
\end{itemize}

%The \hgext{inotify} extension is not yet shipped with Mercurial as of
%May~2007, so it's a little more involved to set up than other
%extensions.  But the performance improvement is worth it!

2007年5月までは\hgext{inotify}拡張はMercurialに同梱されていなかった．その
ため，セットアップは他の拡張に比べてやや複雑だが，得られる性能向上にはそ
れだけの価値がある．

%The extension currently comes in two parts: a set of patches to the
%Mercurial source code, and a library of Python bindings to the
%\texttt{inotify} subsystem.

現在，拡張は2つのパートに分かれている．Mercurialソースコードへのパッチと
\texttt{inotify}サブシステムへのPythonバインディングライブラリである．

\begin{note}
%  There are \emph{two} Python \texttt{inotify} binding libraries.  One
%  of them is called \texttt{pyinotify}, and is packaged by some Linux
%  distributions as \texttt{python-inotify}.  This is \emph{not} the
%  one you'll need, as it is too buggy and inefficient to be practical.

Pythonの\texttt{inotify}バインディングライブラリは\emph{2つ}ある．1つは
\texttt{pyinotify}であり，いくつかのLinuxディストリビューションでは
\texttt{python-inotify}としてパッケージ化されている．これはバグが非常に多
く，実用するには非効率的であり，使うべきで\emph{ない}．
\end{note}

%To get going, it's best to already have a functioning copy of
%Mercurial installed.
先へ進むに当って，正しく機能するMercurialがインストールされていることが
望ましい．

\begin{note}
%  If you follow the instructions below, you'll be \emph{replacing} and
%  overwriting any existing installation of Mercurial that you might
%  already have, using the latest ``bleeding edge'' Mercurial code.
%  Don't say you weren't warned!
以下の指示に従ってインストールしたMercurialを，最新のMercurialコードで
\emph{置き換える}ことができる．（警告されなかったとは言わないこと）

\end{note}
\begin{enumerate}
%\item Clone the Python \texttt{inotify} binding repository.  Build and
%  install it.
\item Python \texttt{inotify}バインディングのリポジトリをクローンし，ビ
      ルドとインストールを行う．
  \begin{codesample4}
    hg clone http://hg.kublai.com/python/inotify
    cd inotify
    python setup.py build --force
    sudo python setup.py install --skip-build
  \end{codesample4}
%\item Clone the \dirname{crew} Mercurial repository.  Clone the
%  \hgext{inotify} patch repository so that Mercurial Queues will be
%  able to apply patches to your cope of the \dirname{crew} repository.
 \item Merecurialの\dirname{crew}リポジトリをクローンす
      る．\hgext{inotify}パッチリポジトリをクローンし，Mercurial Queues
      が\dirname{crew}リポジトリにパッチを当てられるようにする．
  \begin{codesample4}
    hg clone http://hg.intevation.org/mercurial/crew
    hg clone crew inotify
    hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches
  \end{codesample4}
%\item Make sure that you have the Mercurial Queues extension,
%  \hgext{mq}, enabled.  If you've never used MQ, read
%  section~\ref{sec:mq:start} to get started quickly.

\item Mercurial Queues拡張（\hgext{mq}）が有効になっていることを確認す
      る．MQを使ったことがなければ，\ref{sec:mq:start}を一読することをお
      すすめする．

%\item Go into the \dirname{inotify} repo, and apply all of the
%  \hgext{inotify} patches using the \hgxopt{mq}{qpush}{-a} option to
%  the \hgxcmd{mq}{qpush} command.
\item \dirname{inotify}リポジトリへ行き，\hgxcmd{mq}{qpush}コマンドに
      \hgxopt{mq}{qpush}{-a}オプションを使って\hgext{inotify}のパッチをす
      べて適用する．

  \begin{codesample4}
    cd inotify
    hg qpush -a
  \end{codesample4}
%  If you get an error message from \hgxcmd{mq}{qpush}, you should not
%  continue.  Instead, ask for help.

\hgxcmd{mq}{qpush}でエラーが起きた場合，先へ進まずに助言を求めて欲しい．

%\item Build and install the patched version of Mercurial.
\item パッチを当てたMercurialをビルドしてインストールする．
  \begin{codesample4}
    python setup.py build --force
    sudo python setup.py install --skip-build
  \end{codesample4}
\end{enumerate}
%Once you've build a suitably patched version of Mercurial, all you
%need to do to enable the \hgext{inotify} extension is add an entry to
%your \hgrc.

適切なパッチの当ったMercurialをビルドすれば，後は\hgext{inotify}拡張を利
用するように\hgrc を設定するだけである．

\begin{codesample2}
  [extensions]
  inotify =
\end{codesample2}
%When the \hgext{inotify} extension is enabled, Mercurial will
%automatically and transparently start the status daemon the first time
%you run a command that needs status in a repository.  It runs one
%status daemon per repository.

\hgext{inotify}が有効になっていると，Mercurialはリポジトリ内でコマンドが
最初に実行された時に自動的かつ透過的にステータスデーモンを起動する．リポ
ジトリ1つごとに1つのステータスデーモンが起動される．

%The status daemon is started silently, and runs in the background.  If
%you look at a list of running processes after you've enabled the
%\hgext{inotify} extension and run a few commands in different
%repositories, you'll thus see a few \texttt{hg} processes sitting
%around, waiting for updates from the kernel and queries from
%Mercurial.

ステータスデーモンは何も出力を行わず，バックグラウンドで動作す
る．\hgext{inotify}拡張を有効にした後で別のリポジトリ内でいくつかコマンド
を実行し，実行中のプロセスのリストを見ると，いくつかの\texttt{hg}プロセス
がカーネルからのアップデートとMercurialからの問い合わせを待っているのが
見られるだろう．

%The first time you run a Mercurial command in a repository when you
%have the \hgext{inotify} extension enabled, it will run with about the
%same performance as a normal Mercurial command.  This is because the
%status daemon needs to perform a normal status scan so that it has a
%baseline against which to apply later updates from the kernel.
%However, \emph{every} subsequent command that does any kind of status
%check should be noticeably faster on repositories of even fairly
%modest size.  Better yet, the bigger your repository is, the greater a
%performance advantage you'll see.  The \hgext{inotify} daemon makes
%status operations almost instantaneous on repositories of all sizes!

\hgext{inotify}拡張を有効にし，リポジトリ内でMercurialコマンドを最初に実
行した時は通常のMercurialコマンドと同様の性能で動く．ステータスデーモンは
通常のステータススキャンを行い，カーネルから更新の通知を受けるためのベー
スラインを取得しておかなければならないからである．一方で，後続のステータ
スチェックを行う\emph{すべての}コマンドは，そこそこの大きさのリポジトリに
対しても目に見えて高速化される．さらにリポジトリが大きくなるに連れて性能
の向上は大きくなる．\hgext{inotify}デーモンは，リポジトリのサイズに関わら
ず，ステータス取得をほぼ瞬時に行うことができる．

%If you like, you can manually start a status daemon using the
%\hgxcmd{inotify}{inserve} command.  This gives you slightly finer
%control over how the daemon ought to run.  This command will of course
%only be available when the \hgext{inotify} extension is enabled.

\hgxcmd{inotify}{inserve}コマンドを使ってステータスデーモンを手動で実行す
ることも可能である．これにより，デーモンがどのように動作するのかをやや細
かくコントロールすることができる．当然ながら，このコマンドは
\hgext{inotify}が有効の場合のみ利用可能である．


%When you're using the \hgext{inotify} extension, you should notice
%\emph{no difference at all} in Mercurial's behaviour, with the sole
%exception of status-related commands running a whole lot faster than
%they used to.  You should specifically expect that commands will not
%print different output; neither should they give different results.
%If either of these situations occurs, please report a bug.

\hgext{inotify}拡張を使っている時はMercurialの\emph{全く変化なし}という動
作に気付くだろう．ステータスに関係するコマンドは以前よりずっと高速になっ
ているという一つの例外を除いてコマンドは特別の出力も結果も出力しないこと
に留意されたい．何か特別なことが起きたらバグとして報告して欲しい．

%\section{Flexible diff support with the \hgext{extdiff} extension}
\section{\hgext{extdiff}拡張による柔軟なdiffサポート}
\label{sec:hgext:extdiff}

%Mercurial's built-in \hgcmd{diff} command outputs plaintext unified
%diffs.
%\interaction{extdiff.diff}
%If you would like to use an external tool to display modifications,
%you'll want to use the \hgext{extdiff} extension.  This will let you
%use, for example, a graphical diff tool.

Mercurialのビルトインコマンド\hgcmd{diff}はunified形式のdiffをプレーンテ
キストで出力する．
\interaction{extdiff.diff}
変更を外部ツールを使って表示したいならば，\hgext{extdiff}拡張を使うと良
い．この拡張は例えばグラフィカルなdiff表示を行う．

%The \hgext{extdiff} extension is bundled with Mercurial, so it's easy
%to set up.  In the \rcsection{extensions} section of your \hgrc,
%simply add a one-line entry to enable the extension.

\hgext{extdiff}拡張はMercurialに同梱されているので，セットアップは容易で
ある．\hgrc の中の\rcsection{extensions}セクションに1行の設定を追加する
だけで良い．
\begin{codesample2}
  [extensions]
  extdiff =
\end{codesample2}

%This introduces a command named \hgxcmd{extdiff}{extdiff}, which by
%default uses your system's \command{diff} command to generate a
%unified diff in the same form as the built-in \hgcmd{diff} command.
%\interaction{extdiff.extdiff}
%The result won't be exactly the same as with the built-in \hgcmd{diff}
%variations, because the output of \command{diff} varies from one
%system to another, even when passed the same options.

この拡張で\hgxcmd{extdiff}{extdiff}というコマンドが使えるようになる．
このコマンドはシステムの\command{diff}を使って組み込みの\hgcmd{diff}コマ
ンドと同様のunified形式のdiffを生成する．
\interaction{extdiff.extdiff}
得られる成果物は組み込みの\hgcmd{diff}と全く同じにはならないだろう．理由
は\command{diff}コマンドはシステム毎に異なり，同じオプションを渡しても同
じ出力をするとは限らないからだ．

%As the ``\texttt{making snapshot}'' lines of output above imply, the
%\hgxcmd{extdiff}{extdiff} command works by creating two snapshots of
%your source tree.  The first snapshot is of the source revision; the
%second, of the target revision or working directory.  The
%\hgxcmd{extdiff}{extdiff} command generates these snapshots in a
%temporary directory, passes the name of each directory to an external
%diff viewer, then deletes the temporary directory.  For efficiency, it
%only snapshots the directories and files that have changed between the
%two revisions.

出力の``\texttt{making snapshot}''行が主張するよう
に，\hgxcmd{extdiff}{extdiff}コマンドはソースツリーの2つのスナップショッ
トを作るように働く． 1つ目のスナップショットはソースリビジョンで，2つ目は
ワーキングディレクトリのターゲットリビジョンである．
\hgxcmd{extdiff}{extdiff}コマンドはこれらのスナップショットをテンポラリディ
レクトリに作り，外部diffビューアにそれぞれのディレクトリの名前を渡す．そ
の後，テンポラリディレクトリを消去する．効率のために2つのリビジョン間で変
更のあったディレクトリとファイルのスナップショットだけを取る．

%Snapshot directory names have the same base name as your repository.
%If your repository path is \dirname{/quux/bar/foo}, then \dirname{foo}
%will be the name of each snapshot directory.  Each snapshot directory
%name has its changeset ID appended, if appropriate.  If a snapshot is
%of revision \texttt{a631aca1083f}, the directory will be named
%\dirname{foo.a631aca1083f}.  A snapshot of the working directory won't
%have a changeset ID appended, so it would just be \dirname{foo} in

%this example.  To see what this looks like in practice, look again at
%the \hgxcmd{extdiff}{extdiff} example above.  Notice that the diff has
%the snapshot directory names embedded in its header.

スナップショットディレクトリの名前はリポジトリと同じベースネームを持つ．
リポジトリのパスが\dirname{/quux/bar/foo}ならば，\dirname{foo}がスナップ
ショットディレクトリのベースネームになり，ここにチェンジセットIDが付加さ
れる．スナップショットのリビジョンが\texttt{a631aca1083f}なら，ディレクト
リは\dirname{foo.a631aca1083f}となる．ワーキングディレクトリのスナップ
ショットはチェンジセットIDを持たないので，この例では\dirname{foo}という名
前になる．実際の動作を見るには，上記の\hgxcmd{extdiff}{extdiff}を参照され
たい． diffのヘッダにはスナップショットディレクトリ名が埋め込まれている点
に留意されたい．

%The \hgxcmd{extdiff}{extdiff} command accepts two important options.
%The \hgxopt{extdiff}{extdiff}{-p} option lets you choose a program to
%view differences with, instead of \command{diff}.  With the
%\hgxopt{extdiff}{extdiff}{-o} option, you can change the options that
%\hgxcmd{extdiff}{extdiff} passes to the program (by default, these
%options are ``\texttt{-Npru}'', which only make sense if you're
%running \command{diff}).  In other respects, the
%\hgxcmd{extdiff}{extdiff} command acts similarly to the built-in
%\hgcmd{diff} command: you use the same option names, syntax, and
%arguments to specify the revisions you want, the files you want, and
%so on.

\hgxcmd{extdiff}{extdiff}コマンドには重要なオプションが2つある．
\hgxopt{extdiff}{extdiff}{-p}オプションで差分を取るコマンドとして
\command{diff}以外のコマンドを指定できる． \hgxopt{extdiff}{extdiff}{-o}
オプションで\hgxcmd{extdiff}{extdiff}が外部プログラムに渡すオプションを変
更することができる．（デフォルトでは``\texttt{-Npru}''が渡される．これは
\command{diff}が起動される時のみ意味を持つ．）その他の点では
\hgxcmd{extdiff}{extdiff}コマンドはビルトインの\hgcmd{diff}と同様の動作を
する．すなわち，同じオプション名，文法，リビジョンやファイルを指定する書
式などを持つ．

%As an example, here's how to run the normal system \command{diff}
%command, getting it to generate context diffs (using the

%\cmdopt{diff}{-c} option) instead of unified diffs, and five lines of
%context instead of the default three (passing \texttt{5} as the
%argument to the \cmdopt{diff}{-C} option).
%\interaction{extdiff.extdiff-ctx}

ここでシステムの通常コマンドの\command{diff}を，unified diff形式ではな
く，（\cmdopt{diff}{-c}オプションを使って）context diff形式を出力させる例
を見てみよう．context diffに含まれるコンテキストの行数もデフォルトの3行で
はなく，（\cmdopt{diff}{-C}へ\texttt{5}オプションを渡して）5行出力させる
ようにする．

%Launching a visual diff tool is just as easy.  Here's how to launch
%the \command{kdiff3} viewer.
ビジュアルdiffツールの起動はたやすい．ここでは\command{kdiff3}ビューアの
起動方法を示す．
\begin{codesample2}
  hg extdiff -p kdiff3 -o ''
\end{codesample2}

%If your diff viewing command can't deal with directories, you can
%easily work around this with a little scripting.  For an example of
%such scripting in action with the \hgext{mq} extension and the
%\command{interdiff} command, see
%section~\ref{mq-collab:tips:interdiff}.

利用しようとするdiffビューコマンドがディレクトリを扱えない場合，わずかな
スクリプトを書くことで簡単にこの問題を回避することができる．実際に使われ
ているスクリプト例としては，\hgext{mq}拡張と\command{interdiff}コマンドの
間のものがある．これについては\ref{mq-collab:tips:interdiff}を参照された
い．

%\subsection{Defining command aliases}
\subsection{コマンドのエイリアスを作る}

%It can be cumbersome to remember the options to both the
%\hgxcmd{extdiff}{extdiff} command and the diff viewer you want to use,
%so the \hgext{extdiff} extension lets you define \emph{new} commands
%that will invoke your diff viewer with exactly the right options.

\hgxcmd{extdiff}{extdiff}コマンドとdiffビューア双方のオプションを覚えてお
くのは厄介なため，\hgext{extdiff}拡張でdiffビューアを正しいオプションで起
動する\emph{新しい}コマンドを定義することができる．

%All you need to do is edit your \hgrc, and add a section named
%\rcsection{extdiff}.  Inside this section, you can define multiple
%commands.  Here's how to add a \texttt{kdiff3} command.  Once you've
%defined this, you can type ``\texttt{hg kdiff3}'' and the
%\hgext{extdiff} extension will run \command{kdiff3} for you.

このためには\hgrc を編集し\rcsection{extdiff}という名前の新しいセクション
を追加すればよい．このセクション内では複数のコマンドを定義することができ
る．\texttt{kdiff3}コマンドを追加する方法を例として示す．一度定義を行え
ば，``\texttt{hg kdiff3}''とタイプすることで\hgext{extdiff}拡張が
\command{kdiff3}を実行する．

\begin{codesample2}
  [extdiff]
  cmd.kdiff3 =
\end{codesample2}

%If you leave the right hand side of the definition empty, as above,
%the \hgext{extdiff} extension uses the name of the command you defined
%as the name of the external program to run.  But these names don't
%have to be the same.  Here, we define a command named ``\texttt{hg
%  wibble}'', which runs \command{kdiff3}.

上の例のように右辺を空にしておくと，\hgext{extdiff}拡張は外部で起動すべき
コマンド名として定義を用いる．この名前は重複してはならない．ここでは
``\texttt{hg wibble}''という名前でコマンド\command{kdiff3}を呼び出すを定
義している．

\begin{codesample2}
  [extdiff]
  cmd.wibble = kdiff3
\end{codesample2}

%You can also specify the default options that you want to invoke your
%diff viewing program with.  The prefix to use is ``\texttt{opts.}'',
%followed by the name of the command to which the options apply.  This
%example defines a ``\texttt{hg vimdiff}'' command that runs the
%\command{vim} editor's \texttt{DirDiff} extension.

diffビューアを起動する際のデフォルトオプションも定義できる．定義ではオプ
ションを定義したいコマンドの前に``\texttt{opts.}''という接頭辞を付ける．
この例では\command{vim}エディタを\texttt{DirDiff}オプション付きで起動する
``\texttt{hg vimdiff}''コマンドを定義している．

\begin{codesample2}
  [extdiff]
  cmd.vimdiff = vim
  opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
\end{codesample2}

%\section{Cherrypicking changes with the \hgext{transplant} extension}
\section{\hgext{transplant}拡張を用いたチェリーピッキング更新}
\label{sec:hgext:transplant}

%Need to have a long chat with Brendan about this.
（Brendanとよく話をする必要がある．）

%\section{Send changes via email with the \hgext{patchbomb} extension}
\section{\hgext{patchbomb}拡張によって変更をメールする}
\label{sec:hgext:patchbomb}

%Many projects have a culture of ``change review'', in which people
%send their modifications to a mailing list for others to read and
%comment on before they commit the final version to a shared
%repository.  Some projects have people who act as gatekeepers; they
%apply changes from other people to a repository to which those others
%don't have access.

多くのプロジェクトが``更新のレビュー''の文化を持っている．開発者たちは最
終バージョンを共有リポジトリにコミットする前に，パッチを査読者達がいるメー
リングリストへ変更を送り，チェックや受けたりコメントを貰ったりする．いく
つかのプロジェクトでは門番のような人々を持っていたりさえする．彼らの仕事
は，人々から送られた変更を，彼ら以外にアクセス権のないリポジトリへ適用す
ることである．

%Mercurial makes it easy to send changes over email for review or
%application, via its \hgext{patchbomb} extension.  The extension is so
%namd because changes are formatted as patches, and it's usual to send
%one changeset per email message.  Sending a long series of changes by
%email is thus much like ``bombing'' the recipient's inbox, hence
%``patchbomb''.

Mercurialでは\hgext{patchbomb}拡張を用いるとレビューや適用のために変更を
メールで送信することが容易になる．この拡張の名前は変更をパッチとしてフォー
マットし，1つのチェンジセット毎にメール1通を送信することに由来する．
一連の変更を連続してメールで送信することを``爆撃''に見立てている．従って
受信者が受け取るのは``パッチ爆弾''である．

%As usual, the basic configuration of the \hgext{patchbomb} extension
%takes just one or two lines in your \hgrc.
通常，\hgext{patchbomb}拡張の基本設定は\hgrc の中で1，2行ほどである．

\begin{codesample2}
  [extensions]
  patchbomb =
\end{codesample2}
%Once you've enabled the extension, you will have a new command
%available, named \hgxcmd{patchbomb}{email}.

拡張を有効にすると，\hgxcmd{patchbomb}{email}コマンドが使えるようになる．

%The safest and best way to invoke the \hgxcmd{patchbomb}{email}
%command is to \emph{always} run it first with the
%\hgxopt{patchbomb}{email}{-n} option.  This will show you what the
%command \emph{would} send, without actually sending anything.  Once
%you've had a quick glance over the changes and verified that you are
%sending the right ones, you can rerun the same command, with the
%\hgxopt{patchbomb}{email}{-n} option removed.

\hgxcmd{patchbomb}{email}を起動するのに最も安全で良い方法は，まず最初に
\hgxopt{patchbomb}{email}{-n}オプションを付けて実行してみることだ．
これにより，実際の送信は行わずに何が起きるのかを見ることができる．変更に
目を通して正しい変更を送信することを確認できたら，同じコマンドを
\hgxopt{patchbomb}{email}{-n}オプションなしで実行する．

%The \hgxcmd{patchbomb}{email} command accepts the same kind of
%revision syntax as every other Mercurial command.  For example, this
%command will send every revision between 7 and \texttt{tip},
%inclusive.

\hgxcmd{patchbomb}{email}コマンドは他のMercurialコマンドと同様のリビジョ
ン指定構文を受け付ける．例えばリビジョン7からtipまでを含む変更を送信する
などのように指定が可能である．
\begin{codesample2}
  hg email -n 7:tip
\end{codesample2}

%You can also specify a \emph{repository} to compare with.  If you
%provide a repository but no revisions, the \hgxcmd{patchbomb}{email}
%command will send all revisions in the local repository that are not

%present in the remote repository.  If you additionally specify
%revisions or a branch name (the latter using the
%\hgxopt{patchbomb}{email}{-b} option), this will constrain the
%revisions sent.

比較対象として\emph{リポジトリ}を指定することもできる．リポジトリを指定
し，リビジョンを指定しない場合，\hgxcmd{patchbomb}{email}はローカルリポジ
トリにあってリモートリポジトリにない全てのバージョンを送信する．リビジョ
ンまたはブランチ名を指定すると（後者は\hgxopt{patchbomb}{email}{-b}を用い
る），送信されるリビジョンに制限が加わる．

%It's perfectly safe to run the \hgxcmd{patchbomb}{email} command
%without the names of the people you want to send to: if you do this,
%it will just prompt you for those values interactively.  (If you're
%using a Linux or Unix-like system, you should have enhanced
%\texttt{readline}-style editing capabilities when entering those
%headers, too, which is useful.)

送信したい人達の名前を指定せずに\hgxcmd{patchbomb}{email}コマンドを使って
も全く安全である．この場合，対話的に入力を求める．LinuxまたはUnix系のシス
テムを使っていれば，ヘッダの入力に使いやすい\texttt{readline}スタイルの編
集機能を利用できる

%When you are sending just one revision, the \hgxcmd{patchbomb}{email}
%command will by default use the first line of the changeset
%description as the subject of the single email message it sends.

ただ1つのリビジョンを送る場合，\hgxcmd{patchbomb}{email}コマンドはデフォ
ルトでチェンジセットの説明の最初の行をメールの件名として用いる．

%If you send multiple revisions, the \hgxcmd{patchbomb}{email} command
%will usually send one message per changeset.  It will preface the
%series with an introductory message, in which you should describe the
%purpose of the series of changes you're sending.

複数のリビジョンを送る場合，\hgxcmd{patchbomb}{email}コマンドは1つのチェ
ンジセット毎に1通のメールを送信する．開始のメールには一連の変更の目的を記
述する説明文を付ける．


%\subsection{Changing the behaviour of patchbombs}
\subsection{patchbombsの挙動を変更する}

%Not every project has exactly the same conventions for sending changes
%in email; the \hgext{patchbomb} extension tries to accommodate a
%number of variations through command line options.

全てのプロジェクトが同じようなメールによる変更の送付の習慣を持っているわ
けではない．\hgext{patchbomb}拡張はコマンドラインオプションで様々な方法
に対応できるようになっている．

\begin{itemize}
%\item You can write a subject for the introductory message on the
%  command line using the \hgxopt{patchbomb}{email}{-s} option.  This
%  takes one argument, the text of the subject to use.
 \item コマンドラインから\hgxopt{patchbomb}{email}{-s}オプションを使っ
       て，説明文になる件名を入力することができる．このオプションは件名と
       して使われるテキストを引数として取る．

%\item To change the email address from which the messages originate,
%  use the \hgxopt{patchbomb}{email}{-f} option.  This takes one
%  argument, the email address to use.
 \item メッセージの送信元のアドレスを変更するには
       \hgxopt{patchbomb}{email}{-f}オプションを用いる．このオプションは
       メールアドレスを引数として取る．

%\item The default behaviour is to send unified diffs (see
%  section~\ref{sec:mq:patch} for a description of the format), one per
%  message.  You can send a binary bundle instead with the
%  \hgxopt{patchbomb}{email}{-b} option.
 \item デフォルトでは1メッセージ毎にunified形式diffを送信する．（このフォー
       マットについては\ref{sec:mq:patch}を参
       照．）\hgxopt{patchbomb}{email}{-b}オプションを使えば，バイナリ形
       式のデータを添付することもできる．

%\item Unified diffs are normally prefaced with a metadata header.  You
%  can omit this, and send unadorned diffs, with the
%  \hgxopt{patchbomb}{email}{--plain} option.
 \item unified形式diffは通常メタデータのヘッダを持
       つ．\hgxopt{patchbomb}{email}{--plain}オプションを使うことでこれ
       を割愛することができる．

%\item Diffs are normally sent ``inline'', in the same body part as the
%  description of a patch.  This makes it easiest for the largest
%  number of readers to quote and respond to parts of a diff, as some
%  mail clients will only quote the first MIME body part in a message.
%  If you'd prefer to send the description and the diff in separate
%  body parts, use the \hgxopt{patchbomb}{email}{-a} option.
 \item 通常，差分はパッチの説明と同じボディの中に``インライン''で書き込ま
       れる．いくつかのメールクライアントでは最初のMIMEパートのみから引用
       が可能なため，こうすることが最も多くの人にとってパッチの特定の部分
       にコメントしたりするのに好都合である．説明文とdiffを別のボディパー
       トにして送信したい場合は\hgxopt{patchbomb}{email}{-a}オプションを
       使う．

%\item Instead of sending mail messages, you can write them to an
%  \texttt{mbox}-format mail folder using the
%  \hgxopt{patchbomb}{email}{-m} option.  That option takes one
%  argument, the name of the file to write to.
 \item メールでメッセージを送信する変わり
       に，\hgxopt{patchbomb}{email}{-m}オプションを使って
       \texttt{mbox}フォーマットで出力させることも可能だ．
       このオプションは出力ファイル名を一つオプションとして取る．

%\item If you would like to add a \command{diffstat}-format summary to
%  each patch, and one to the introductory message, use the
%  \hgxopt{patchbomb}{email}{-d} option.  The \command{diffstat}
%  command displays a table containing the name of each file patched,
%  the number of lines affected, and a histogram showing how much each
%  file is modified.  This gives readers a qualitative glance at how
%  complex a patch is.
 \item \command{diffstat}フォーマットのサマリを各々のパッチに付け，説明文
       を付けたい場合は，\hgxopt{patchbomb}{email}{-d}オプションを使うと
       良い．\command{diffstat}コマンドはパッチされた各々のファイル名，影
       響を受けた行数，各ファイルがどれだけ変更されたかを示すヒストグラム
       をを含むテーブルを表示する．この情報は，パッチの複雑さについて定性
       的な理解を得るのに役立つ．

\end{itemize}

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