%\chapter{Collaborating with other people}
\chapter{他の人々との共同作業}
\label{cha:collab}

%As a completely decentralised tool, Mercurial doesn't impose any
%policy on how people ought to work with each other.  However, if
%you're new to distributed revision control, it helps to have some
%tools and examples in mind when you're thinking about possible
%workflow models.

完全な分散型ツールとして，Mercurialはユーザが他のユーザとどのように作業す
るかのポリシーを強要することはない．しかし初めて分散リビジョンコントロー
ルツールを使うのであれば，いくつかのツールの使用法と使用例を知ることが
取り得るワークフローモデルを考える際に助けとなるであろう．

%\section{Mercurial's web interface}
\section{Mercurialのウェブインタフェース}

%Mercurial has a powerful web interface that provides several
%useful capabilities.

Mercurialはいくつかの有用な機能を持つ強力なウェブインタフェースを備えて
いる．

%For interactive use, the web interface lets you browse a single
%repository or a collection of repositories.  You can view the history
%of a repository, examine each change (comments and diffs), and view
%the contents of each directory and file. You can even get a view of
%history that gives a graphical view of the relationships between
%individual changes and merges.

対話的な利用では，ウェブインタフェースにより1つのリポジトリまたはいくつか
のリポジトリのコレクションを閲覧することができる．リポジトリの履歴を見た
り，各々の変更（コメントや差分を含む）を調べたり，ディレクトリやファイル
の内容を見ることができる．また，履歴を表示し，個々の変更やマージの関係を
グラフィカルに表示することも可能である．

%Also for human consumption, the web interface provides Atom and RSS feed
%of the changes in a repository.  This lets you ``subscribe'' to a
%repository using your favorite feed reader, and be automatically
%notified of activity in that repository as soon as it happens.  I find
%this capability much more convenient than the model of subscribing to
%a mailing list to which notifications are sent, as it requires no
%additional configuration on the part of whoever is serving the
%repository.

ウェブインタフェースは閲覧用にリポジトリの変更のAtomおよびRSSフィードを提
供する．これを使えば，リポジトリの変化を好みのフィードリーダによって``購
読''することができ，リポジトリでの活動が起こるとすぐさま通知を受けられ
る．この機能は誰がリポジトリのサービスを行っても追加の設定を必要としない
ため，メーリングリストを購読して通知を受けるモデルよりもずっと便利である．

%The web interface also lets remote users clone a repository, pull
%changes from it, and (when the server is configured to permit it) push
%changes back to it.  Mercurial's HTTP tunneling protocol aggressively
%compresses data, so that it works efficiently even over low-bandwidth
%network connections.

リモートユーザはウェブインタフェースを用いてリポジトリをクローンすること
もできる．変更をpullして，（サーバが許可する設定になっていれば）加えた変
更を再びpushすることもできる．MercurialのHTTPトンネルプロトコルはデータを
積極的に圧縮するため，バンド幅の低いネットワークコネクションでも有効に機
能する．

%The easiest way to get started with the web interface is to use your
%web browser to visit an existing repository, such as the master
%Mercurial repository at
%\url{http://www.selenic.com/repo/hg}.

ウェブインタフェースの最も簡単な始め方はウェブブラウザを使ってMercurialの
マスタリポジトリ\url{http://www.selenic.com/repo/hg}のような既存のリポジ
トリを参照することである．

%If you're interested in providing a web interface to your own
%repositories, there are several good ways to do this.

自分のリポジトリにウェブインタフェースを用意する場合，いくつか良い方法が
ある．

%The easiest and fastest way to get started in an informal environment is
%to use the \hgcmd{serve} command, which is best suited to short-term
%``lightweight'' serving.  See section~\ref{sec:collab:serve} below for
%details of how to use this command.  If you have a long-lived
%repository that you'd like to make permanently available, Mercurial
%has built-in support for the CGI (Common Gateway Interface) standard,
%which all common web servers support.  See
%section~\ref{sec:collab:cgi} for details of CGI configuration.

公式ではない環境で行う最も簡単で早い方法は，\hgcmd{serve}コマンドを使う方
法で，これは短期間の``手軽な''サービスに的している．このコマンドの詳細な
使用法については下記の~\ref{sec:collab:serve}節を参照のこと．リポジトリを
長期間にわたり永続的にサービスしたい場合は，Mercurialに内蔵のCGI(Common
Gateway Interface)サポートを利用することができる． CGIの設定について
は~\ref{sec:collab:cgi}節を参照のこと．

%\section{Collaboration models}
\section{共同作業モデル}

%With a suitably flexible tool, making decisions about workflow is much
%more of a social engineering challenge than a technical one.
%Mercurial imposes few limitations on how you can structure the flow of
%work in a project, so it's up to you and your group to set up and live
%with a model that matches your own particular needs.

適切で柔軟なツールをもってしても，ワークフローに関する決定をすることは技
術的というよりは社会工学的なチャレンジである． Mercurialがプロジェクトの
ワークフローに課す制限はほとんどないため，これをいかに構築するかはあなた
とその共同作業者に任されており，固有の要求マッチするモデルを作ることがで
きる．

%\subsection{Factors to keep in mind}
\subsection{考慮すべき要素}

%The most important aspect of any model that you must keep in mind is
%how well it matches the needs and capabilities of the people who will
%be using it.  This might seem self-evident; even so, you still can't
%afford to forget it for a moment.

どのようなモデルを使う場合でも，それが作業する人々の要求と能力に適ったも
のであるかを常に念頭に置くことが最も重要である．
これは自明のことのように思えるかもしれないが，片時も忘れてはならない．

%I once put together a workflow model that seemed to make perfect sense
%to me, but that caused a considerable amount of consternation and
%strife within my development team.  In spite of my attempts to explain
%why we needed a complex set of branches, and how changes ought to flow
%between them, a few team members revolted.  Even though they were
%smart people, they didn't want to pay attention to the constraints we
%were operating under, or face the consequences of those constraints in
%the details of the model that I was advocating.

自分にとって完全と思えるワークフローモデルを構築したつもりが，共同開発チー
ムにとっては大きな驚きと葛藤を与えてしまったことがある．複雑なブランチの
集合がなぜ必要なのか変更がブランチ間でどのように伝播するのかを説明したに
もかかわらず，幾人かのチームメンバーは反発した．彼らは聡明であったが，私
の拘ったルールが作業に与える制限や，モデルの細部に与える影響に注意を払う
ことを望まなかった．

%Don't sweep foreseeable social or technical problems under the rug.
%Whatever scheme you put into effect, you should plan for mistakes and
%problem scenarios.  Consider adding automated machinery to prevent, or
%quickly recover from, trouble that you can anticipate.  As an example,
%if you intend to have a branch with not-for-release changes in it,
%you'd do well to think early about the possibility that someone might
%accidentally merge those changes into a release branch.  You could
%avoid this particular problem by writing a hook that prevents changes
%from being merged from an inappropriate branch.

将来起こり得る社会的または技術的問題に目を瞑ってはならない．どのような方
法をとるにしても，間違いや問題が起きた場合に備えておく必要がある．想像し
得るトラブルを防止したり，トラブルから素早く回復させるための自動化された
方法を考えておく必要がある．たとえば，リリースに含めない変更を行ったブラ
ンチがあるとしたら，誰かが誤ってそこからリリースブランチに変更をマージし
てしまう可能性について検討しておくべきである．この場合であれば，不適切な
ブランチからのマージを禁止するフックを用意することで問題を回避することが
できる．

%\subsection{Informal anarchy}
\subsection{非公式な混乱}

%I wouldn't suggest an ``anything goes'' approach as something
%sustainable, but it's a model that's easy to grasp, and it works
%perfectly well in a few unusual situations.

ここで述べる``なんでもあり''アプローチが持続可能であると言いたいわけでは
ないのだが，このモデルは把握しやすく，いくつかの状況ではうまく機能するも
のだ．

%As one example, many projects have a loose-knit group of collaborators
%who rarely physically meet each other.  Some groups like to overcome
%the isolation of working at a distance by organizing occasional
%``sprints''.  In a sprint, a number of people get together in a single
%location (a company's conference room, a hotel meeting room, that kind
%of place) and spend several days more or less locked in there, hacking
%intensely on a handful of projects.

例えばプロジェクトの多くは実際にはほとんど会うことのない協力者たちの緩や
かなグループを持つ．グループのいくつかは機会毎に短い``スプリント''を形成
し，離れた場所での隔絶した作業を克服している．スプリントでは，（企業の会
議室，ホテルのミーティングルームのような）一カ所に集まって数日間にわたっ
て少数のプロジェクトを集中的にハックする．

%A sprint or a hacking session in a coffee shop are the perfect places to
%use the \hgcmd{serve} command, since \hgcmd{serve} does not requires any
%fancy server infrastructure.  You can get started with \hgcmd{serve} in
%moments, by reading section~\ref{sec:collab:serve} below.  Then simply
%tell the person next to you that you're running a server, send the URL
%to them in an instant message, and you immediately have a
%quick-turnaround way to work together.  They can type your URL into
%their web browser and quickly review your changes; or they can pull a
%bugfix from you and verify it; or they can clone a branch containing a
%new feature and try it out.

スプリントやコーヒーショップでのハッキングセッションは\hgcmd{serve}コマン
ドを使うのまさににうってつけの環境である． \hgcmd{serve}は手の込んだサー
バ設備を必要としない．下の\ref{sec:collab:serve}セクションを読んですぐに
\hgcmd{serve}コマンドを使うことができる．サーバを起動していることを隣の開
発者に話したり，グループにURLをインスタントメッセージで送れば，すぐに迅速
な共同作業ができる．送ったURLを他の開発者がブラウザに入力すれば，彼らは簡
単にあなたの変更をレビューすることができるし，あなたの行ったバグフィック
スをpullして検証することもできる．さらに，新機能の実装されたブランチをク
ローンして試すこともできる．

%The charm, and the problem, with doing things in an ad hoc fashion
%like this is that only people who know about your changes, and where
%they are, can see them.  Such an informal approach simply doesn't
%scale beyond a handful people, because each individual needs to know
%about \emph{n} different repositories to pull from.

アドホックなやり方で行う共同作業の魅力と問題は，あなたの変更を知ってい
て，場所も分かっている人々しか変更を参照できないことである．このような非
公式なアプローチは，各人が\emph{n}個の異なったリポジトリのどれからpullを
行えばいいか分かっている必要があるため，少人数以上にスケールしない．


%\subsection{A single central repository}
\subsection{1つの集中リポジトリ}

%For smaller projects migrating from a centralised revision control
%tool, perhaps the easiest way to get started is to have changes flow
%through a single shared central repository.  This is also the
%most common ``building block'' for more ambitious workflow schemes.

集中型リビジョンコントロールツールを使っていた小規模なプロジェクトが移行
する場合には，中央に単一の共有リポジトリを設けて，その中で変更を管理する
のが最も簡単な方法であろう．このようなリポジトリはもっと曖昧なワークフロー
スキームにとっても共通の基盤となる．

%Contributors start by cloning a copy of this repository.  They can
%pull changes from it whenever they need to, and some (perhaps all)
%developers have permission to push a change back when they're ready
%for other people to see it.

協力者はリポジトリのコピーをクローンすることから始める．そして必要な時に
変更をpullし，幾人かの（全員かもしれない）開発者は，自分の行った変更を必
要な時にpushする権限を持つ．

%Under this model, it can still often make sense for people to pull
%changes directly from each other, without going through the central
%repository.  Consider a case in which I have a tentative bug fix, but
%I am worried that if I were to publish it to the central repository,
%it might subsequently break everyone else's trees as they pull it.  To
%reduce the potential for damage, I can ask you to clone my repository
%into a temporary repository of your own and test it.  This lets us put
%off publishing the potentially unsafe change until it has had a little
%testing.

このモデルでも，中央のリポジトリを参照せず他の開発者のリポジトリから直接
変更をpullすることには意味がある．手元で仮のバグ修正を行ったが，これを中
央のリポジトリで公開し，他の開発者達がpullすると各々のソースツリーが壊れ
るおそれがある場合を考える．ダメージの可能性を下げるために，別の開発者に
自分のリポジトリをクローンし，テストすることを依頼することが考えられる．
この方法を取ることで，最低限のテストを行うまで，問題のある可能性のある変
更を公開することを引き延ばすことができる．

%If a team is hosting its own repository in this kind of scenario, people
%usually use the \command{ssh} protocol to securely push changes to the
%central repository, as documented in section~\ref{sec:collab:ssh}. It's
%also usual to publish a read-only copy of the repository over HTTP, as
%in section~\ref{sec:collab:cgi}. Publishing over HTTP satisfies the
%needs of people who don't have push access, and those who want to use
%web browsers to browse the repository's history.

この状況では，開発者たちは通常，中央のリポジトリへ変更をプッシュするため
に，~\ref{sec:collab:ssh}節で説明したように\command{ssh}プロトコルを用い
る．また~\ref{sec:collab:cgi}節で述べたように，リポジトリの読み取り専用コ
ピーをHTTPで公開するのも一般的である． HTTPによる公開で，プッシュアクセス
権を持たない人々やリポジトリの履歴をブラウザで参照したい人のニーズを満た
すことができる．

%\subsection{A hosted central repository}
\subsection{ホスティングによる中央リポジトリサービス}

%A wonderful thing about public hosting services like Bitbucket
%(\url{http://bitbucket.org}) is that not only do they handle the
%fiddly server configuration details, such as user accounts,
%authentication, and secure wire protocols, they provide additional
%infrastructure to make this model work well.

Bitbucket(\url{http://bitbucket.org})のような公共のホスティングサービスで
は，ユーザアカウントの設定，認証，セキュアな通信プロトコルなどの面倒なサー
バ設定を肩代りしてくれるだけでなく，このモデルがもっと良く機能するための
インフラを提供している．

%For instance, a well-engineered hosting service will let
%people clone their own copies of a repository with a single
%click.  This lets people work in separate spaces and share
%their changes when they're ready.

例えば，うまく構成されたホスティングサービスは，1クリックでリポジトリのコ
ピーをクローンできるようになっている．これにより，別々の場所で作業を行
い，準備が出来次第変更を共有することができるようになる．

%In addition, a good hosting service will let people communicate with
%each other, for instance to say ``there are changes ready for you to
%review in this tree''.

また，良いホスティングサービスは，開発者同士が``このツリーにレビューして
貰いたい変更がある''などのやりとりをできるような機能も提供している．

%\subsection{Working with multiple branches}
\subsection{複数のブランチでの作業}

%Projects of any significant size naturally tend to make progress on
%several fronts simultaneously.  In the case of software, it's common
%for a project to go through periodic official releases.  A release
%might then go into ``maintenance mode'' for a while after its first
%publication; maintenance releases tend to contain only bug fixes, not
%new features.  In parallel with these maintenance releases, one or
%more future releases may be under development.  People normally use
%the word ``branch'' to refer to one of these many slightly different
%directions in which development is proceeding.

ある程度の規模のプロジェクトでは，自ずといくつもの前線で開発を進めていく
ようになる．ソフトウェアの場合，定期的に公式リリースを行うのが通例であ
る．リリースは，公開後暫くして``メンテナンスモード''に移行するかもしれな
い．メンテナンスリリースではバグの修正だけを行い，新機能の追加は行わない
のが通例である．これらのメンテナンスリリースと並行して，将来のリリースが
開発される．通常，開発の進行していく若干異なった方向の各々を表すために
``ブランチ''という呼称を用いる．

%Mercurial is particularly well suited to managing a number of
%simultaneous, but not identical, branches.  Each ``development
%direction'' can live in its own central repository, and you can merge
%changes from one to another as the need arises.  Because repositories
%are independent of each other, unstable changes in a development
%branch will never affect a stable branch unless someone explicitly
%merges those changes into the stable branch.

Mercurialは複数ブランチによる同時開発を取り扱うことに特に適している．各々
の``開発方向''は中央リポジトリに置くことが可能で，必要になる度にあるブラ
ンチから別のブランチへマージできる．リポジトリはそれぞれ独立であるため，
開発ブランチでの不安定な変更は，開発者の誰かが明示的にマージを行わない限
り安定版ブランチにはなんの影響も与えない．

%Here's an example of how this can work in practice.  Let's say you
%have one ``main branch'' on a central server.
%\interaction{branching.init}
%People clone it, make changes locally, test them, and push them back.

実際にどのように動作するのかを例で示す．中央のサーバに1つの``メインブラ
ンチ''があるとしよう．
\interaction{branching.init}
開発者はこれをクローンし，ローカルで変更を加え，テストし，またpushすると
する．

%Once the main branch reaches a release milestone, you can use the
%\hgcmd{tag} command to give a permanent name to the milestone
%revision.
%\interaction{branching.tag}
%Let's say some ongoing development occurs on the main branch.
%\interaction{branching.main}
%Using the tag that was recorded at the milestone, people who clone
%that repository at any time in the future can use \hgcmd{update} to
%get a copy of the working directory exactly as it was when that tagged
%revision was committed.
%\interaction{branching.update}

メインブランチがリリースマイルストーンに到達した際に，\hgcmd{tag}で永続的
な名前をマイルストーンリビジョンに付けることができる．
\interaction{branching.tag}
メインブランチで進行中の開発について見てみよう．
\interaction{branching.main}
これ以後リポジトリをクローンした人はマイルストーンで記録されたタグと
\hgcmd{update}コマンドを使って，タグの付けられたリビジョンと全く同じワー
キングディレクトリを復元することができる．
\interaction{branching.update}

%In addition, immediately after the main branch is tagged, we can then
%clone the main branch on the server to a new ``stable'' branch, also on
%the server.
%\interaction{branching.clone}

さらに，メインブランチがタグ付けされた直後からサーバ上のメインブランチを
新たな``stable''ブランチにクローンできる．これはサーバ上で行うことも可能
である．
\interaction{branching.clone}

%If we need to make a change to the stable branch, we can then clone
%\emph{that} repository, make our changes, commit, and push our changes
%back there.
%\interaction{branching.stable}
%Because Mercurial repositories are independent, and Mercurial doesn't
%move changes around automatically, the stable and main branches are
%\emph{isolated} from each other.  The changes that we made on the
%main branch don't ``leak'' to the stable branch, and vice versa.

stableブランチに変更を加えたい場合，\emph{その}リポジトリをクローンし，
変更を行い，コミットした後にその変更をサーバにpushすることができる．
\interaction{branching.stable}
Mercurialリポジトリは独立で，変更を自動的に波及させることもないので，
stableとmainブランチは互いに\emph{隔離されている}．メインブランチに行っ
た変更がstableブランチに漏れ出したり，その逆になったりすることはない．

%We'll often want all of your bugfixes on the stable branch to show up
%on the main branch, too.  Rather than rewrite a bugfix on the main
%branch, we can simply pull and merge changes from the stable to the
%main branch, and Mercurial will bring those bugfixes in for us.
%\interaction{branching.merge}

多くの場合，stableブランチに対して行ったバグ修正をメインブランチに対して
も取り込みたいと考えるだろう．バグ修正をメインブランチでもう一度行うので
はなく，Mercurialを使って変更をstableブランチからpullして簡単にメインブラ
ンチへマージすることができる．
\interaction{branching.merge}

%The main branch will still contain changes that are not on the stable
%branch, but it will also contain all of the bugfixes from the stable
%branch.  The stable branch remains unaffected by these changes, since
%changes are only flowing from the stable to the main branch, and not the
%other way.

メインブランチはstableブランチにあるバグ修正をすべて取り込んでいるだけで
なく， stableブランチにはない変更も持っている．この操作を行ってもstableブ
ランチはこれらの変更による影響を受けない．なぜなら変更はstableブランチか
らメインブランチへの一方向のみに波及し，逆向きには波及しないからである．

%\subsection{Feature branches}
\subsection{機能によるブランチ}

%For larger projects, an effective way to manage change is to break up
%a team into smaller groups.  Each group has a shared branch of its
%own, cloned from a single ``master'' branch used by the entire
%project.  People working on an individual branch are typically quite
%isolated from developments on other branches.

大規模なプロジェクトで変更を効果的に管理する方法は，チームを小さなグルー
プに分割することである．各々のグループはプロジェクト全体で使われる単一の
マスターブランチからクローンした固有の共有ブランチを持つ．各々のブランチ
で作業する人達は，他のブランチでの開発から隔離されているのが通例である．

\begin{figure}[ht]
  \centering
  \grafix{feature-branches}
%  \caption{Feature branches}
  \caption{機能によるブランチ}
  \label{fig:collab:feature-branches}
\end{figure}

%When a particular feature is deemed to be in suitable shape, someone
%on that feature team pulls and merges from the master branch into the
%feature branch, then pushes back up to the master branch.

特定の機能が十分な状態になったとき，その機能のチームメンバーはマスターブ
ランチから機能ブランチにpullとマージを行い，マスターブランチにpushして戻
す．

%\subsection{The release train}
\subsection{リリーストレイン}

%Some projects are organized on a ``train'' basis: a release is
%scheduled to happen every few months, and whatever features are ready
%when the ``train'' is ready to leave are allowed in.

いくつかのプロジェクトはトレイン方式で組織されている．数カ月に一度リリー
スを行うようにスケジュールされ，トレインが出発できるように新機能が準備さ
れる．

%This model resembles working with feature branches.  The difference is
%that when a feature branch misses a train, someone on the feature team
%pulls and merges the changes that went out on that train release into
%the feature branch, and the team continues its work on top of that
%release so that their feature can make the next release.

このモデルは機能ブランチでの作業と似ている．違いは，機能ブランチはトレイ
ンを逃した場合，機能チームのメンバーが機能ブランチのトレインリリースへ行
くべき変更を機能リリースにpullおよびマージし，開発中の機能が次のリリース
に入るようにチームはそのリリースの上で作業を続ける．

%\subsection{The Linux kernel model}
\subsection{Linuxカーネルモデル}

%The development of the Linux kernel has a shallow hierarchical
%structure, surrounded by a cloud of apparent chaos.  Because most
%Linux developers use \command{git}, a distributed revision control
%tool with capabilities similar to Mercurial, it's useful to describe
%the way work flows in that environment; if you like the ideas, the
%approach translates well across tools.

Linuxカーネルの開発では，周りに混沌とした広がりを持つ浅い階層構造が取られ
ている．殆んどのLinux開発者はMercurialと同様の機能を持つ\command{git}とい
う分散リビジョン管理ツールを利用しているため，彼らが取っているワークフロー
を述べることは我々にも役立つ．彼らのアイディアを気に入れば，そのアプロー
チはツールの違いを越えて有効である．

%At the center of the community sits Linus Torvalds, the creator of
%Linux.  He publishes a single source repository that is considered the
%``authoritative'' current tree by the entire developer community.
%Anyone can clone Linus's tree, but he is very choosy about whose trees
%he pulls from.

開発コミュニティの中心はLinuxの創造者であるLinus Torvaldsである．彼はリポ
ジトリを1つ公開しており，それは開発コミュニティ全体の公式カレントツリーと
見做されている．誰でもLinusのツリーをクローンできるが，彼自身はどこから
pullするかを厳しく選んでいる．

%Linus has a number of ``trusted lieutenants''.  As a general rule, he
%pulls whatever changes they publish, in most cases without even
%reviewing those changes.  Some of those lieutenants are generally
%agreed to be ``maintainers'', responsible for specific subsystems
%within the kernel.  If a random kernel hacker wants to make a change
%to a subsystem that they want to end up in Linus's tree, they must
%find out who the subsystem's maintainer is, and ask that maintainer to
%take their change.  If the maintainer reviews their changes and agrees
%to take them, they'll pass them along to Linus in due course.

Linusは多くの``信頼できる代行者''を持っている．原則的には彼は彼らが公開し
たものは何でもpullする．多くの場合，彼らの変更をレビューすることもしな
い．代行者の何人かはメンテナとなることを同意しており，カーネル内の特定の
サブシステムに対して責任を持つ．カーネルハッカーの誰かがLinusのツリーのサ
ブシステムに変更を加えたいと思ったら，サブシステムのメンテナを見つけ出し
た上で，メンテナに変更を取り込んで貰うように依頼する必要がある．メンテナ
が変更をレビューし，取り込むことに同意すれば，正式なコースで変更をLinusに
手渡す．

%Individual lieutenants have their own approaches to reviewing,
%accepting, and publishing changes; and for deciding when to feed them
%to Linus.  In addition, there are several well known branches that
%people use for different purposes.  For example, a few people maintain
%``stable'' repositories of older versions of the kernel, to which they
%apply critical fixes as needed.  Some maintainers publish multiple
%trees: one for experimental changes; one for changes that they are
%about to feed upstream; and so on.  Others just publish a single
%tree.

それぞれの代理人はレビュー，変更の公開，いつLinusに提出するかについてそれ
ぞれ独自のアプローチを取っている．また，別の用途向けによく知られたブラン
チがいくつかあり，例えば幾人かの人はカーネルの過去のバージョンの
``stable''リポジトリをメンテナンスし，重要な修正を行っている．別のメンテ
ナは，実験的な変更を取り込むツリー，上流に手渡す寸前の変更を取り込むツリー
などのように複数のツリーを公開している．また1つのツリーだけを公開している
メンテナも多い．

%This model has two notable features.  The first is that it's ``pull
%only''.  You have to ask, convince, or beg another developer to take a
%change from you, because there are almost no trees to which more than
%one person can push, and there's no way to push changes into a tree
%that someone else controls.

このモデルは注目すべき特長を2つ持っている．第一に，これらはpullオンリーで
ある．変更を取り込んで貰うためには，他の開発者に依頼したり，説得したり，
懇願したりしなければならない．なぜなら2人以上がプッシュできるツリーはほと
んどなく，別の人がコントロールしているツリーに変更をpushする術はないから
である．

%The second is that it's based on reputation and acclaim.  If you're an
%unknown, Linus will probably ignore changes from you without even
%responding.  But a subsystem maintainer will probably review them, and
%will likely take them if they pass their criteria for suitability.
%The more ``good'' changes you contribute to a maintainer, the more
%likely they are to trust your judgment and accept your changes.  If
%you're well-known and maintain a long-lived branch for something Linus
%hasn't yet accepted, people with similar interests may pull your
%changes regularly to keep up with your work.

第二に，これは評判と称賛によるシステムであるということだ．無名の開発者の
変更に対してはLinusはおそらく反応することなく無視する．しかしサブシステム
メンテナは変更をレビューし，適切であると判断すれば採り入れる．開発者が良
い変更を行えば行うほど，メンテナは開発者の判断を信用し，変更を採り入れる
ようになるだろう．開発者が著名で，Linusがいまだに受け入れていない，長期間
にわたるブランチのメンテナであるならば，同じ興味を持つ人々が彼の作業を取
り込むために変更を定期的にpullすることだろう．

%Reputation and acclaim don't necessarily cross subsystem or ``people''
%boundaries.  If you're a respected but specialised storage hacker, and
%you try to fix a networking bug, that change will receive a level of
%scrutiny from a network maintainer comparable to a change from a
%complete stranger.

評判と称賛はサブシステムを越えたり，周辺にいる人々を越えることはないだろ
う．もしあなたがストレージの分野で敬意を集めるハッカーであったとしても，
ネットワークのバグを修正しようとしたのなら，行った変更はネットワークのメ
ンテナから完全な部外者と同等の精査を受けることになるだろう．

%To people who come from more orderly project backgrounds, the
%comparatively chaotic Linux kernel development process often seems
%completely insane.  It's subject to the whims of individuals; people
%make sweeping changes whenever they deem it appropriate; and the pace
%of development is astounding.  And yet Linux is a highly successful,
%well-regarded piece of software.

整然としたプロジェクトから来た開発者にとっては，Linuxカーネルの混沌とした
開発プロセスはしばしば完全に狂気の沙汰と思えることだろう．Linuxカーネルで
は，開発プロセスは個々人の気まぐれに依存しており，適切と考えた時は全面的
な変更を行い，開発ペースは途方もない．それでもしかしLinuxは大いに成功した
注目すべきソフトウェアなのである．

%\subsection{Pull-only versus shared-push collaboration}
\subsection{Pullのみ vs 共有pushコラボレーション}

%A perpetual source of heat in the open source community is whether a
%development model in which people only ever pull changes from others
%is ``better than'' one in which multiple people can push changes to a
%shared repository.

オープンソースコミュニティでは他の開発者のところから変更をpullするだけの
開発モデルが，共有リポジトリに多数の開発者がpushできるモデルよりも``優れ
ている''かどうかが常に激しい論争の種になる．

%Typically, the backers of the shared-push model use tools that
%actively enforce this approach.  If you're using a centralised
%revision control tool such as Subversion, there's no way to make a
%choice over which model you'll use: the tool gives you shared-push,
%and if you want to do anything else, you'll have to roll your own
%approach on top (such as applying a patch by hand).

共有プッシュモデルの支持者は，このアプローチを強制するようなツールを使っ
ていることが多い．もしSubversionのような中央集中型のリビジョン管理ツール
を使っているのなら，使うモデルを選ぶ余地はそもそも存在しない．
これらのツールでは共有pushモデルを使う他なく，それ以外の何かをしたいので
あれば，（自力でパッチを当てるなどの方法で）外部で行う必要がある．

%A good distributed revision control tool will support both models.  You
%and your collaborators can then structure how you work together based on
%your own needs and preferences, not on what contortions your tools force
%you into.

良い分散リビジョンコントロールツールは，両方のモデルをサポートする．ユー
ザや協力者はツールによって強要されるモデルではなく，要求や好みに応じた共
同作業の構成を決めることができる．

%\subsection{Where collaboration meets branch management}
\subsection{共同作業がブランチ管理と直面するところ}

%Once you and your team set up some shared repositories and start
%propagating changes back and forth between local and shared repos, you
%begin to face a related, but slightly different challenge: that of
%managing the multiple directions in which your team may be moving at
%once.  Even though this subject is intimately related to how your team
%collaborates, it's dense enough to merit treatment of its own, in
%chapter~\ref{chap:branch}.

開発者とそのチームが共有リポジトリをセットアップし，ローカルと共有リポジ
トリの間で変更をやりとりし始めると，これと関連するが，やや異なった困難に
直面するようになるだろう．それは，チームが同時に進める多方面への開発をど
のように管理するかという問題である．この課題は，チームがどのように共同す
るかと根源的に関係しており，これだけのために~\ref{chap:branch}という一章を
費やす価値があるだろう．

%\section{The technical side of sharing}
\section{共有の技術的側面}

%The remainder of this chapter is devoted to the question of sharing
%changes with your collaborators.

この章の残りの部分では，協力者と変更を共有する際の疑問点について述べる．

%\section{Informal sharing with \hgcmd{serve}}
\section{\hgcmd{serve}による非公式な共有}
\label{sec:collab:serve}

%Mercurial's \hgcmd{serve} command is wonderfully suited to small,
%tight-knit, and fast-paced group environments.  It also provides a
%great way to get a feel for using Mercurial commands over a network.

Mercurialの\hgcmd{serve}コマンドは，小規模で緊密な開発ペースの速いグルー
プ環境にとても適している．Mercurialコマンドをネットワーク越しに使う素晴
らしさを体感できるだろう．

%Run \hgcmd{serve} inside a repository, and in under a second it will
%bring up a specialised HTTP server; this will accept connections from
%any client, and serve up data for that repository until you terminate
%it.  Anyone who knows the URL of the server you just started, and can
%talk to your computer over the network, can then use a web browser or
%Mercurial to read data from that repository.  A URL for a
%\hgcmd{serve} instance running on a laptop is likely to look something
%like \Verb|http://my-laptop.local:8000/|.

リポジトリ内で\hgcmd{serve}コマンドを起動すると，すぐさま特別なHTTPサーバ
が立ち上げられる．これはあらゆるクライアントからの接続を受け入れ，リポジ
トリのデータをサービスする．起動したサーバのURLを知っている人やあなたのコ
ンピュータにネットワークを介して接続可能な人は誰でも，ウェブブラウザや
Mercurialを使ってリポジトリからデータを読み出すことができる．ラップトップ
で起動された\hgcmd{serve}インスタンスへのURLは
\Verb|http://my-laptop.local:8000/|のようになる．

%The \hgcmd{serve} command is \emph{not} a general-purpose web server.
%It can do only two things:
\hgcmd{serve}コマンドは一般用途向けのウェブサーバでは\emph{ない}．このコ
マンドは次の2つのことだけを行う：
\begin{itemize}
%\item Allow people to browse the history of the repository it's
%  serving, from their normal web browsers.
 \item 普通のウェブブラウザを使っているユーザに対してはリポジトリの履歴
       への参照．
%\item Speak Mercurial's wire protocol, so that people can
%  \hgcmd{clone} or \hgcmd{pull} changes from that repository.
 \item Mercurialを使っているユーザに対しては，\hgcmd{clone}または
       \hgcmd{pull}ができるようにMercurialワイヤプロトコルのサポート．

\end{itemize}
%In particular, \hgcmd{serve} won't allow remote users to \emph{modify}
%your repository.  It's intended for read-only use.

\hgcmd{serve}はリモートユーザにリポジトリの変更を許可しない．このコマン
ドは読み出しのみの使用を意図している．

%If you're getting started with Mercurial, there's nothing to prevent
%you from using \hgcmd{serve} to serve up a repository on your own
%computer, then use commands like \hgcmd{clone}, \hgcmd{incoming}, and
%so on to talk to that server as if the repository was hosted remotely.
%This can help you to quickly get acquainted with using commands on
%network-hosted repositories.

Mercurialの\hgcmd{serve}コマンドを使って，簡単に手元のコンピュータでリポ
ジトリサービスを行うことができる．遠方にあるサーバとやりとりするのと同様
に\hgcmd{clone}，\hgcmd{incoming}等のコマンドを使うことができる．これはネッ
トワークでリポジトリを提供する練習になるだろう．

%\subsection{A few things to keep in mind}
\subsection{覚えておくべき2, 3の点}

%Because it provides unauthenticated read access to all clients, you
%should only use \hgcmd{serve} in an environment where you either don't
%care, or have complete control over, who can access your network and
%pull data from your repository.

\hgcmd{serve}は，認証なしでアクセスを許すため，ネットワークへのアクセス
や，リポジトリからのデータpullを誰が行っても構わないようなネットワーク環
境や，完全な制御が可能なネットワーク環境でのみ使用すべきである．

%The \hgcmd{serve} command knows nothing about any firewall software
%you might have installed on your system or network.  It cannot detect
%or control your firewall software.  If other people are unable to talk
%to a running \hgcmd{serve} instance, the second thing you should do
%(\emph{after} you make sure that they're using the correct URL) is
%check your firewall configuration.

\hgcmd{serve}コマンドは，システムやネットワークにインストールされているファ
イアウォールソフトウェアについては何も関知しない．このコマンドはファイア
ウォールの発見や制御はできない．他のユーザが\hgcmd{serve}コマンドにアクセ
スできない場合，まず彼らが正しいURLを使用しているか確認し，その次にすべき
ことは，ファイアウォールの設定を確認することである．

%By default, \hgcmd{serve} listens for incoming connections on
%port~8000.  If another process is already listening on the port you
%want to use, you can specify a different port to listen on using the
%\hgopt{serve}{-p} option.

デフォルトでは\hgcmd{serve}は到着する接続をポート~8000で待つ．
使用したいポートをすでに他のプロセスが使用している場合は
\hgopt{serve}{-p}オプションを使って別のポートで待機するように指定するこ
とができる．

%Normally, when \hgcmd{serve} starts, it prints no output, which can be
%a bit unnerving.  If you'd like to confirm that it is indeed running
%correctly, and find out what URL you should send to your
%collaborators, start it with the \hggopt{-v} option.

通常，\hgcmd{serve}は始動してもメッセージの出力を行わない．これは多少混乱
させるかもしれない．実際に正しく動作しているかどうか確認したい場合や，協
力者に教えるURLが知りたい場合は\hggopt{-v}オプションを指定する．

%\section{Using the Secure Shell (ssh) protocol}
\section{Secure Shell (ssh)プロトコルの使用}
\label{sec:collab:ssh}

%You can pull and push changes securely over a network connection using
%the Secure Shell (\texttt{ssh}) protocol.  To use this successfully,
%you may have to do a little bit of configuration on the client or
%server sides.

Secure Shell (\texttt{ssh})プロトコルを使うことで，変更をネットワーク上で
安全にpushできる．このプロトコルの利用には，クライアント側かサーバ側に少々
設定が必要である．

%If you're not familiar with ssh, it's the name of both a command and a
%network protocol that let you securely communicate with another
%computer. To use it with Mercurial, you'll be setting up one or more
%user accounts on a server so that remote users can log in and execute
%commands.

sshに馴染みのないユーザのために説明すると，sshは他のコンピュータと安全に
通信を行うためのコマンドおよびネットワークプロトコルの名称である．
Mercurialで使うためには，1つ以上のアカウントをサーバに設定し，リモートユー
ザがログインし，コマンドを実行できるようにする必要がある．

%(If you \emph{are} familiar with ssh, you'll probably find some of the
%material that follows to be elementary in nature.)

（sshに馴染みのあるユーザには以下の話は初歩的に感じられるに違いない．）

%\subsection{How to read and write ssh URLs}
\subsection{sshのURLをどのように読むか}

%An ssh URL tends to look like this:
ssh URLは一般に次のようになる：
\begin{codesample2}
  ssh://bos@hg.serpentine.com:22/hg/hgbook
\end{codesample2}
\begin{enumerate}
%\item The ``\texttt{ssh://}'' part tells Mercurial to use the ssh
%  protocol.
 \item ``\texttt{ssh://}''部はMercurialにsshプロトコルを使うことを指示す
       る．
%\item The ``\texttt{bos@}'' component indicates what username to log
%  into the server as.  You can leave this out if the remote username
%  is the same as your local username.
 \item ``\texttt{bos@}''部はサーバへのログインに使うユーザ名を指定する．
ローカルマシンでのユーザ名と同じものを使用する場合は指定しなくてもよい．
%\item The ``\texttt{hg.serpentine.com}'' gives the hostname of the
%  server to log into.
 \item ``\texttt{hg.serpentine.com}''はログインするサーバのホスト名であ
       る．
%\item The ``:22'' identifies the port number to connect to the server
%  on.  The default port is~22, so you only need to specify this part
%  if you're \emph{not} using port~22.
 \item ``:22''サーバの接続ポートを制定する．デフォルトポートは~22なの
       で，22番以外を使う時のみ指定する必要がある．
%\item The remainder of the URL is the local path to the repository on
%  the server.
 \item URLの残りの部分はサーバ上のリポジトリへのローカルパスである．
\end{enumerate}

%There's plenty of scope for confusion with the path component of ssh
%URLs, as there is no standard way for tools to interpret it.  Some
%programs behave differently than others when dealing with these paths.
%This isn't an ideal situation, but it's unlikely to change.  Please
%read the following paragraphs carefully.

ssh URLのパス部については，ツール向けに変換する標準的な方法がないため，混
乱が多い．いくつかのプログラムと，その他のプログラムではパスを扱う際の挙
動が異なっている．この状況は理想とはかけ離れているが，修正するのは困難だ
と思われる．以下の段落を注意深く読んで欲しい．

%Mercurial treats the path to a repository on the server as relative to
%the remote user's home directory.  For example, if user \texttt{foo}
%on the server has a home directory of \dirname{/home/foo}, then an ssh
%URL that contains a path component of \dirname{bar}
%\emph{really} refers to the directory \dirname{/home/foo/bar}.
Mercurialはリポジトリへのパスをリモートユーザのホームディレクトリからの相
対パスとして取り扱う．例えばサーバでユーザ\texttt{foo}はホームディレクト
リ\dirname{/home/foo}を持つ．従って\dirname{bar}を含むssh URLのパス部は
\dirname{/home/foo/bar}となる．

%If you want to specify a path relative to another user's home
%directory, you can use a path that starts with a tilde character
%followed by the user's name (let's call them \texttt{otheruser}), like
%this.
他のユーザのホームディレクトリへの相対パスを指定したい場合は，次の例のよ
うにチルダにユーザ名を続けたパスを使うことができる．（ここでは他のユーザ
のユーザ名を\texttt{otheruser}とする．）
\begin{codesample2}
  ssh://server/~otheruser/hg/repo
\end{codesample2}

%And if you really want to specify an \emph{absolute} path on the
%server, begin the path component with two slashes, as in this example.
サーバ上で絶対パスを指定したい場合は，次の例のようにパス部を2つのスラッシュ
で始める．
\begin{codesample2}
  ssh://server//absolute/path
\end{codesample2}

%\subsection{Finding an ssh client for your system}
\subsection{利用中のシステム向けのssh clientを見つける}

%Almost every Unix-like system comes with OpenSSH preinstalled.  If
%you're using such a system, run \Verb|which ssh| to find out if
%the \command{ssh} command is installed (it's usually in
%\dirname{/usr/bin}).  In the unlikely event that it isn't present,
%take a look at your system documentation to figure out how to install
%it.

Unix系システムの殆んどはOpenSSHがプリインストールされている．そのようなシ
ステムでは，\Verb|which ssh|を実行して\command{ssh}コマンドがインストール
されているかどうか調べることができる．（普通は\dirname{/usr/bin}にインス
トールされているはずだ．）万が一インストールされていなかった場合は，シス
テムのドキュメントを参照してインストール方法を調べて欲しい．

%On Windows, the TortoiseHg package is bundled with a version of Simon
%Tatham's excellent \command{plink} command, and you should not
%need to do any further configuration.

Windowsでは，TortoiseHgパッケージにSimon Tathamによる優れたコマンドである
\command{plink}が同梱されており，何も設定することなく利用可能である．

%\subsection{Generating a key pair}
\subsection{鍵ペアの作成}

%To avoid the need to repetitively type a password every time you need to
%use your ssh client, I recommend generating a key pair.

sshクライアントを使う度に繰返しパスワードを入力するのを避けるために，鍵
ペアを作成することを勧める．

\begin{note}
%Key pairs are not mandatory
鍵ペアは必須ではない

%Mercurial knows nothing about ssh authentication or key pairs.  You can,
%if you like, safely ignore this section and the one that follows until
%you grow tired of repeatedly typing ssh passwords.

Mercurial自身はsshでの認証や鍵ペアについては一切関知しない．sshパスワード
の入力に倦むことがなければ，この節と後の節を無視しても差し支えない．
\end{note}

\begin{itemize}
% \item On a Unix-like system, the \command{ssh-keygen} command will do
%       the trick.
 \item Unix系システムでは，\command{ssh-keygen}コマンドで鍵ペアを作成できる．
% \item On Windows, if you're using TortoiseHg, you may need to download
%       a command named \command{puttygen} from the PuTTY web site
%       \url{http://www.chiark.greenend.org.uk/~sgtatham/putty} to
%       generate a key pair. See the \command{puttygen} documentation
%       \url{http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.htm}
%       for details of how use the command.
 \item WindowsでTortoiseHgを使っているのであれば，PuTTYのウェブサイト
       \url{http://www.chiark.greenend.org.uk/~sgtatham/putty}からダウン
       ロードできる\command{puttygen}というコマンドで鍵ペア
       を作成できる．このコマンドの使用法の詳細については
       \command{puttygen}のドキュメント
       \url{http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.htm}
       を参照されたい．
\end{itemize}

%When you generate a key pair, it's usually \emph{highly} advisable to
%protect it with a passphrase.  (The only time that you might not want
%to do this id when you're using the ssh protocol for automated tasks
%on a secure network.)

鍵ペアを作る際にはできるだけパスフレーズで保護することを強く勧める．（安
全なネットワークでsshプロトコルによって自動タスクの実行をする場合にはこ
うしたくないだろう．）

%Simply generating a key pair isn't enough, however.  You'll need to
%add the public key to the set of authorised keys for whatever user
%you're logging in remotely as.  For servers using OpenSSH (the vast
%majority), this will mean adding the public key to a list in a file
%called \sfilename{authorized\_keys} in their \sdirname{.ssh}
%directory.

しかし鍵ペアを作るだけでは十分でない．リモートにログインしたいマシンのユー
ザのauthorised keysとして公開鍵を追加する必要がある．OpenSSHを使っている
サーバ（大部分が相当する）では\sdirname{.ssh}ディレクトリの
\sfilename{authorized\_keys}ファイルへ公開鍵を追加する．

%On a Unix-like system, your public key will have a \filename{.pub}
%extension.  If you're using \command{puttygen} on Windows, you can
%save the public key to a file of your choosing, or paste it from the
%window it's displayed in straight into the
%\sfilename{authorized\_keys} file.

Unix系システムでは公開鍵は\filename{.pub}という拡張子を持つ．Windowsで
\command{puttygen}を使用する場合は，ファイルセーブした公開鍵か，鍵を表示
しているウィンドウから\sfilename{authorized\_keys}ファイルにペーストすれ
ばよい．

%\subsection{Using an authentication agent}
\subsection{認証エージェントの使用}

%An authentication agent is a daemon that stores passphrases in memory
%(so it will forget passphrases if you log out and log back in again).
%An ssh client will notice if it's running, and query it for a
%passphrase.  If there's no authentication agent running, or the agent
%doesn't store the necessary passphrase, you'll have to type your
%passphrase every time Mercurial tries to communicate with a server on
%your behalf (e.g.~whenever you pull or push changes).

認証エージェントはパスフレーズをメモリに保存するエージェントである．（ロ
グアウトし，再びログインした時にはパスフレーズは失われている．）sshクライ
アントはこのデーモンが動作していることを認識し，パスフレーズの問い合わせ
を行う．認証エージェントが動作していない場合やエージェントが必要なパスフ
レーズを保存していない場合は，Mercurialがサーバと（変更をpullやpushする）
通信の時にパスフレーズを入力する必要がある．

%The downside of storing passphrases in an agent is that it's possible
%for a well-prepared attacker to recover the plain text of your
%passphrases, in some cases even if your system has been power-cycled.
%You should make your own judgment as to whether this is an acceptable
%risk.  It certainly saves a lot of repeated typing.

パスフレーズをエージェントに記憶させる弊害は，パワーサイクルを行っても場
合によっては周到な手段を用いる攻撃者にパスフレーズのプレーンテキスト情報
を取得される可能性があることである．このリスクが許容できるかどうかは自分
自身で判断して欲しい．この方法を用いることで，タイプ回数を減らせることは
確かである．

%On Unix-like systems, the agent is called \command{ssh-agent}, and
%it's often run automatically for you when you log in.  You'll need to
%use the \command{ssh-add} command to add passphrases to the agent's
%store.

Unix系システムではエージェントは\command{ssh-agent}と呼ばれ，ログインする
と自動的に起動される．\command{ssh-add}コマンドを用いてパスフレーズをエー
ジェントに記憶させる．

%On Windows, if you're using TortoiseHg, the <command>pageant</command>
%command acts as the agent.  As with \command{puttygen}, you'll need to
%download \command{pageant}
%\url{http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html}
%from the PuTTY web site and read its documentation
%\url{http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant}.
%The \command{pageant} command adds an icon to your system tray that will
%let you manage stored passphrases.

WindowsでTortoiseHgを使っている場合は，\command{pageant}コマンドがエージェ
ントとして動作する． \command{puttygen}コマンドの時と同様に
\command{pageant}コマンドはPuTTYのウェブサイト
\url{http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html}から
ダウンロードできる．使用法については
\url{http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant}
を参照されたい． \command{pageant}コマンドは記憶したパスフレーズを管理す
るためにシステムトレイにアイコンを追加する．

%\subsection{Configuring the server side properly}
\subsection{サーバの正しい設定}

%Because ssh can be fiddly to set up if you're new to it, a variety of
%things can go wrong.  Add Mercurial on top, and there's plenty more
%scope for head-scratching.  Most of these potential problems occur on
%the server side, not the client side. The good news is that once you've
%gotten a configuration working, it will usually continue to work
%indefinitely.

sshは慣れていないと設定が難しいため，新たに使い始める場合，様々な不具合が
起きる可能性がある．Mercurialと共に動かす場合，さらに多くが待ち構えてい
る．これらの殆んどがクライアント側ではなくサーバ側で起きる．しかし一度き
ちんと動作する設定をしてしまえば，動作はずっと続く．

%Before you try using Mercurial to talk to an ssh server, it's best to
%make sure that you can use the normal \command{ssh} or \command{putty}
%command to talk to the server first.  If you run into problems with
%using these commands directly, Mercurial surely won't work.  Worse, it
%will obscure the underlying problem.  Any time you want to debug
%ssh-related Mercurial problems, you should drop back to making sure
%that plain ssh client commands work first, \emph{before} you worry
%about whether there's a problem with Mercurial.

Mercurialからsshサーバに接続する前に，\command{ssh}または\command{putty}
コマンドを使ってサーバに接続してみることを勧める．これらのコマンドを直接
使って問題が起きるようであれば，Mercurialは動作しないはずだ． sshの上で
Mercurialを使うことで，下位の問題が隠れてしまうので，sshに関連した
Mercurialの問題をデバッグする時は，まずsshクライアントコマンド自体が動作
することを確認し，その後にMercurialの問題を解決すべきである．

%The first thing to be sure of on the server side is that you can
%actually log in from another machine at all.  If you can't use
%\command{ssh} or \command{putty} to log in, the error message you get
%may give you a few hints as to what's wrong.  The most common problems
%are as follows.

サーバ側でまず確認すべきなのは，他のマシンからログインできるかどうかであ
る． \command{ssh}または\command{putty}コマンドでログインできない場合は，
エラーメッセージに何が悪いのか示すヒントがあるかも知れない．最も一般的な
問題を以下に列挙する．
\begin{itemize}
%\item If you get a ``connection refused'' error, either there isn't an
%  SSH daemon running on the server at all, or it's inaccessible due to
%  firewall configuration.
 \item ``connection refused''エラーが出る時は，SSHデーモンが動作していな
       いか，ファイアウォール設定のためにマシンへのアクセスが不可能であ
       る可能性がある．
%\item If you get a ``no route to host'' error, you either have an
%  incorrect address for the server or a seriously locked down firewall
%  that won't admit its existence at all.
 \item ``no route to host''エラーが出る場合は，サーバのアドレスを間違え
       ているか，ファイアウォールがサーバを完全に隠してしまっていること
       が考えられる．
%\item If you get a ``permission denied'' error, you may have mistyped
%  the username on the server, or you could have mistyped your key's
%  passphrase or the remote user's password.
 \item ``permission denied''エラーが出る場合は，ユーザ名を間違って入力し
       ているか，ログイン用鍵のパスフレーズやユーザパスワードを間違って
       入力している可能性がある．
\end{itemize}
%In summary, if you're having trouble talking to the server's ssh
%daemon, first make sure that one is running at all.  On many systems
%it will be installed, but disabled, by default.  Once you're done with
%this step, you should then check that the server's firewall is
%configured to allow incoming connections on the port the ssh daemon is
%listening on (usually~22).  Don't worry about more exotic
%possibilities for misconfiguration until you've checked these two
%first.

まとめると，サーバのsshデーモンへ接続する際には，まずデーモンが動作してい
るかを確認すること．デフォルトでインストールされてはいるが，停止されてい
るシステムもある．これを確認した後でサーバのファイアウォールがsshデーモン
の待機してるポート（通常は22番）への接続を許可しているか確認する．他の諸々
の可能性を考える前にまずこの2点を確認すべきである．

%If you're using an authentication agent on the client side to store
%passphrases for your keys, you ought to be able to log into the server
%without being prompted for a passphrase or a password.  If you're
%prompted for a passphrase, there are a few possible culprits.

クライアント側で鍵のパスフレーズを記憶させるために認証エージェントを動か
しているなら，パスフレーズやパスワードの入力を促されることなしにサーバに
ログインできるはずだ．もしパスフレーズの入力を要求されるなら，いくつかの
可能性が考えられる．
\begin{itemize}
%\item You might have forgotten to use \command{ssh-add} or
%  \command{pageant} to store the passphrase.
 \item パスフレーズを記憶させるために\command{ssh-add}または
       \command{pageant}を実行していない．
%\item You might have stored the passphrase for the wrong key.
 \item 別のキーのパスフレーズを記憶させている．
\end{itemize}
%If you're being prompted for the remote user's password, there are
%another few possible problems to check.
リモートユーザのパスワードを要求される場合は別の問題があるかもしれない．
\begin{itemize}
%\item Either the user's home directory or their \sdirname{.ssh}
%  directory might have excessively liberal permissions.  As a result,

%  the ssh daemon will not trust or read their
%  \sfilename{authorized\_keys} file.  For example, a group-writable
%  home or \sdirname{.ssh} directory will often cause this symptom.
 \item ユーザのホームディレクトリまたは\sdirname{.ssh}ディレクトリのパー
       ミッションが緩すぎる．このため，sshデーモンが
       \sfilename{authorized\_keys}\sfilename{authorized\_keys}ファイルを
       信頼できないか，あるいは単純に読めない．例えばグループ書き込みパー
       ミッションのあるホームディレクトリまたは\sdirname{.ssh}ディレクト
       リはこの問題をしばしば引き起こす．
%\item The user's \sfilename{authorized\_keys} file may have a problem.
%  If anyone other than the user owns or can write to that file, the
%  ssh daemon will not trust or read it.
 \item ユーザの\sfilename{authorized\_keys}ファイルに問題がある．ファイ
       ルの所有者が別のユーザだったり，他のユーザが書き込みできる場合は
       sshデーモンはこのファイルを信頼せず，読み込まない．
\end{itemize}

%In the ideal world, you should be able to run the following command
%successfully, and it should print exactly one line of output, the
%current date and time.
理想では，次のコマンドを実行し，1行で現在の日時を表示できるべきである．
\begin{codesample2}
  ssh myserver date
\end{codesample2}

%If, on your server, you have login scripts that print banners or other
%junk even when running non-interactive commands like this, you should
%fix them before you continue, so that they only print output if
%they're run interactively.  Otherwise these banners will at least
%clutter up Mercurial's output.  Worse, they could potentially cause
%problems with running Mercurial commands remotely.  Mercurial makes
%tries to detect and ignore banners in non-interactive \command{ssh}
%sessions, but it is not foolproof.  (If you're editing your login
%scripts on your server, the usual way to see if a login script is
%running in an interactive shell is to check the return code from the
%command \Verb|tty -s|.)

サーバで，バナーやその他の意味のない文字列を表示するようなログインスクリ
プトを使っている場合，対話的なコマンド以外ではこれらを表示しないようにす
る．これらの文字列はMercurialの出力に混入してしまい，Mercurialコマンドを
リモート実行する妨げとなる．
Mercurialは非対話的な\command{ssh}ではこれらのバナーを検出し，無視しよう
と試みるが，これは万全ではない．（サーバのログインスクリプトを編集する場
合，ログインスクリプトが対話的シェルで動作しているかを知る方法とし
て，\Verb|tty -s|コマンドのリターンコードをチェックする方法がある．）

%Once you've verified that plain old ssh is working with your server,
%the next step is to ensure that Mercurial runs on the server.  The
%following command should run successfully:
ssh単体でサーバに接続できることを確認したら，Mercurialがサーバで動作する
ことを確認する．次のコマンドが動くかどうか調べてみよう：
\begin{codesample2}
  ssh myserver hg version
\end{codesample2}
%If you see an error message instead of normal \hgcmd{version} output,
%this is usually because you haven't installed Mercurial to
%\dirname{/usr/bin}.  Don't worry if this is the case; you don't need
%to do that.  But you should check for a few possible problems.
\hgcmd{version}の出力ではなくエラーメッセージが表示されるとき
は，\dirname{/usr/bin}にMercurialがインストールされていないことが多い．
この場合，\dirname{/usr/bin}にインストールし直す必要はない．その代わり，
いくつかの問題をチェックすべきである．
\begin{itemize}
%\item Is Mercurial really installed on the server at all?  I know this
%  sounds trivial, but it's worth checking!
 \item サーバにMercurialは本当にインストールされているか？ これは下らな
       い問いのように思えるが，確認する価値はある．
%\item Maybe your shell's search path (usually set via the \envar{PATH}
%  environment variable) is simply misconfigured.
 \item シェルのサーチパスが正しく設定されていない．（通常は環境変数
       \envar{PATH}で設定される．）

%\item Perhaps your \envar{PATH} environment variable is only being set
%  to point to the location of the \command{hg} executable if the login

%  session is interactive.  This can happen if you're setting the path
%  in the wrong shell login script.  See your shell's documentation for
%  details.
 \item 対話的なログインセッションのとき以外は環境変数\envar{PATH}が
       \command{hg}実行ファイルのあるパスを指していない．\envar{PATH}を不
       適切なログインスクリプトで設定しているとこの問題が起きる．詳しくは
       シェルのドキュメントを参照すること．
%\item The \envar{PYTHONPATH} environment variable may need to contain
%  the path to the Mercurial Python modules.  It might not be set at
%  all; it could be incorrect; or it may be set only if the login is
%  interactive.
 \item 環境変数\envar{PYTHONPATH}がMercurial Pythonモジュールを含む必要
       がある場合．これが全く設定されていないか，対話的なログインでのみ
       有効になっている．
\end{itemize}

%If you can run \hgcmd{version} over an ssh connection, well done!
%You've got the server and client sorted out.  You should now be able
%to use Mercurial to access repositories hosted by that username on
%that server.  If you run into problems with Mercurial and ssh at this
%point, try using the \hggopt{--debug} option to get a clearer picture
%of what's going on.

ssh接続で\hgcmd{version}を実行できたのなら準備は完了だ．サーバとクライア
ントの設定は正しく行われている．これでサーバ側のユーザ名を使ってホストさ
れているリポジトリにMercurialを使ってアクセスできるようになった．ここで問
題があるのなら，\hggopt{--debug}オプションを使って何が問題なのかをより明
確に把握して欲しい．

%\subsection{Using compression with ssh}
\subsection{sshでの圧縮の利用}

%Mercurial does not compress data when it uses the ssh protocol,
%because the ssh protocol can transparently compress data.  However,
%the default behaviour of ssh clients is \emph{not} to request
%compression.

Mercurialは，sshプロトコルを使った場合は，データの圧縮は行わない．sshプロ
トコルが透過的にデータの圧縮を行うことができるためである．しかしsshクライ
アントのデフォルトの挙動では，圧縮を行わ\emph{ない}．

%Over any network other than a fast LAN (even a wireless network),
%using compression is likely to significantly speed up Mercurial's
%network operations.  For example, over a WAN, someone measured
%compression as reducing the amount of time required to clone a
%particularly large repository from~51 minutes to~17 minutes.

高速なLAN以外のネットワーク（ワイヤレスネットワークも含む）で
は，Mercurialのネットワーク動作を高速化するのに圧縮の使用はとても効果的で
ある．あるユーザの計測によれば，WAN経由での大規模なリポジトリのクローン
は，圧縮を使うことで~51分から~17分に短縮することができた．

%Both \command{ssh} and \command{plink} accept a \cmdopt{ssh}{-C}
%option which turns on compression.  You can easily edit your \hgrc\ to
%enable compression for all of Mercurial's uses of the ssh protocol.
%Here is how to do so for regular \command{ssh} on Unix-like systems, for
%example.

\command{ssh}コマンドも\command{plink}コマンドも圧縮を有効にする
\cmdopt{ssh}{-C}オプションが使える． \hgrc\ ファイルを編集してMercurialが
圧縮つきのsshプロトコルを使用するように設定することができる． Unix系シス
テムで通常の\command{ssh}コマンドを設定する例は次のようになる．
\begin{codesample2}
  [ui]
  ssh = ssh -C
\end{codesample2}

%If you use \command{ssh} on a Unix-like system, you can configure it to
%always use compression when talking to your server. To do this, edit
%your \sfilename{.ssh/config} file (which may not yet exist), as follows.

Unix系システムで\command{ssh}を用いてサーバへ接続している場合，サーバへの
接続時に常に圧縮を使用するように設定することができる．設定には
\sfilename{.ssh/config}ファイル（存在しない場合は作成する）を次のように編
集する．

\begin{codesample2}
  Host hg
    Compression yes
    HostName hg.example.com
\end{codesample2}

%This defines a hostname alias, \texttt{hg}.  When you use that hostname
%on the \command{ssh} command line or in a Mercurial
%\texttt{ssh}-protocol URL, it will cause \command{ssh} to connect to
%\texttt{hg.example.com} and use compression.  This gives you both a
%shorter name to type and compression, each of which is a good thing in
%its own right.

これはホスト名のエイリアス\texttt{hg}を定義する．このホスト名を
\command{ssh}のコマンドラインまたはMercurial \texttt{ssh}-プロトコルでの
URLで使用すると，\command{ssh}コマンドは\texttt{hg.example.com}への接続に
圧縮を用いる．この方法で短縮形のホスト名と圧縮の設定を同時に行うことがで
きる．

%\section{Serving over HTTP using CGI}
\section{CGIを使用したHTTPによるサービス}
\label{sec:collab:cgi}

%The simplest way to host one or more repositories in a permanent way is
%to use a web server and Mercurial's CGI support.

一つまたは複数のリポジトリを永続的にサービスする最も簡単な方法は，ウェブ
サーバでMercurialのCGIサポートを利用することである．

%Depending on how ambitious you are, configuring Mercurial's CGI
%interface can take anything from a few moments to several hours.

MercurialのCGIインタフェースの設定にかかる時間は，目的とするところに応じ
て数分から数時間程度の幅がある．

%We'll begin with the simplest of examples, and work our way towards a
%more complex configuration.  Even for the most basic case, you're
%almost certainly going to need to read and modify your web server's
%configuration.

ここでは最も単純な例から始めて，より複雑な設定へ進んでいくことにしよう．
最も単純なケースでもおそらくウェブサーバの設定を調べて変更する必要がある
だろう．

\begin{note}
High pain tolerance required

%Configuring a web server is a complex, fiddly, and highly
%system-dependent activity.  I can't possibly give you instructions that
%will cover anything like all of the cases you will encounter. Please use
%your discretion and judgment in following the sections below.  Be
%prepared to make plenty of mistakes, and to spend a lot of time reading
%your server's error logs.

ウェブサーバの設定は複雑かつ厄介でシステム依存の作業である．
読者が遭遇するすべてのケースについて手引きをすることはできないだろう．
以下のセクションでは，読みながら読者自身の思慮と判断を働かせて欲しい．
たくさんのミスを犯し，サーバのエラーログの解読に多くの時間を割くことにな
るのを肝に銘じておいて欲しい．

%If you don't have a strong stomach for tweaking configurations over and
%over, or a compelling need to host your own services, you might want to
%try one of the public hosting services that I mentioned earlier.

延々と設定の手直しを続けることが我慢できなかったり，自前のサービスが必須
でなかったりする場合は，前述の公共ホスティングサービスを検討した方が良い
だろう．

\end{note}

%\subsection{Web server configuration checklist}
\subsection{Webサーバ設定のチェックリスト}

%Before you continue, do take a few moments to check a few aspects of
%your system's setup.
ここから先へ進む前に，読者のシステムについて確認をしておこう．

\begin{enumerate}
% \item Do you have a web server installed at all? Mac OS X and some
%       Linux distributions ship with Apache, but many other systems may
%       not have a web server installed.
 \item ウェブサーバはすでにインストールされているか？ Mac OS Xやいくつか
       のLinuxディストリビューションでは標準でApacheがインストールされて
       いるが，ウェブサーバがインストールされていないシステムも多くある．
%\item If you have a web server installed, is it actually running?  On
%  most systems, even if one is present, it will be disabled by
%  default.
 \item ウェブサーバがインストールされている場合，すでに動作しているか？
       多くのシステムでは，デフォルトで停止されている．
%\item Is your server configured to allow you to run CGI programs in
%  the directory where you plan to do so?  Most servers default to
%  explicitly disabling the ability to run CGI programs.
 \item ウェブサーバはCGIプログラムを目的のディレクトリで動作できるように
       設定されているか？ 大半のサーバではデフォルトでCGIプログラムの動
       作を明示的に禁じている．
\end{enumerate}

%If you don't have a web server installed, and don't have substantial
%experience configuring Apache, you should consider using the
%\texttt{lighttpd} web server instead of Apache.  Apache has a
%well-deserved reputation for baroque and confusing configuration.
%While \texttt{lighttpd} is less capable in some ways than Apache, most
%of these capabilities are not relevant to serving Mercurial
%repositories.  And \texttt{lighttpd} is undeniably \emph{much} easier
%to get started with than Apache.

ウェブサーバがインストールされていない場合や，Apachの設定に十分な経験がな
い場合は，Apacheではなく\texttt{lighttpd}ウェブサーバを検討した方がよいだ
ろう．Apacheは奇異で混乱する設定で悪名が高い． \texttt{lighttpd}はApache
よりもできることが少ないが，それらはMercurialリポジトリのサービスとは関係
がない． \texttt{lighttpd}はApacheよりも明らかに簡単に使うことができる．

%\subsection{Basic CGI configuration}
\subsection{CGIの基本的な設定}

%On Unix-like systems, it's common for users to have a subdirectory
%named something like \dirname{public\_html} in their home directory,
%from which they can serve up web pages.  A file named \filename{foo}
%in this directory will be accessible at a URL of the form
%\texttt{http://www.example.com/\~username/foo}.

Unix系システムでは，ユーザのホームディレクトリにウェブページをサービスす
るための\dirname{public\_html}というサブディレクトリがあることが普通であ
る．このディレクトリ内の\filename{foo}というファイルは
\texttt{http://www.example.com/\~username/foo}というURLでアクセスできる．

%To get started, find the \sfilename{hgweb.cgi} script that should be
%present in your Mercurial installation.  If you can't quickly find a
%local copy on your system, simply download one from the master
%Mercurial repository at
%\url{http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi}.

まずインストールされているMercurialから\sfilename{hgweb.cgi}スクリプトを
見つける．すぐにローカルコピーが見つからなければ，Mercurialのマスターリ
ポジトリ \url{http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi} か
らダウンロードする．

%You'll need to copy this script into your \dirname{public\_html}
%directory, and ensure that it's executable.

このスクリプトを\dirname{public\_html}ディレクトリにコピーし，ファイルが
実行可能であるかをチェックする．
\begin{codesample2}
  cp .../hgweb.cgi ~/public_html
  chmod 755 ~/public_html/hgweb.cgi
\end{codesample2}
%The \texttt{755} argument to \command{chmod} is a little more general
%than just making the script executable: it ensures that the script is
%executable by anyone, and that ``group'' and ``other'' write
%permissions are \emph{not} set.  If you were to leave those write
%permissions enabled, Apache's \texttt{suexec} subsystem would likely
%refuse to execute the script.  In fact, \texttt{suexec} also insists
%that the \emph{directory} in which the script resides must not be
%writable by others.

\command{chmod}コマンドへ\texttt{755}を渡すと，スクリプトは実行可能よりも
若干一般的になる．スクリプトは誰からも実行可能だが，``group''と``other''
のユーザからは書き込めなくなる．書き込みパーミッションが有効である
と，Apacheの\texttt{suexec}サブシステムはスクリプトの実行を拒否する可能性
が高い．実際のところ，\texttt{suexec}はさらにスクリプトの置かれている
\emph{ディレクトリ}が他のユーザの書き込みを拒否する設定であることを要求す
る．

\begin{codesample2}
  chmod 755 ~/public_html
\end{codesample2}

%\subsubsection{What could \emph{possibly} go wrong?}
\subsubsection{どこが問題と成り得るか?}
\label{sec:collab:wtf}

%Once you've copied the CGI script into place, go into a web browser,
%and try to open the URL \url{http://myhostname/~myuser/hgweb.cgi},
%\emph{but} brace yourself for instant failure.  There's a high
%probability that trying to visit this URL will fail, and there are
%many possible reasons for this.  In fact, you're likely to stumble
%over almost every one of the possible errors below, so please read
%carefully.  The following are all of the problems I ran into on a
%system running Fedora~7, with a fresh installation of Apache, and a
%user account that I created specially to perform this exercise.

CGIスクリプトを所定の場所にコピーしたら，ウェブブラウザを起動して
\url{http://myhostname/~myuser/hgweb.cgi} を開く．しかしこのURLにアクセス
してもエラーがでる可能性が高いので，落ち着いて欲しい．エラーには多くの理
由が考えられ，実際，そのすべてに引っ掛かっている可能性が高いので，以下の
記述を注意深く読んで欲しい．ここに挙げたのは，Fedora~7で，新規にインストー
ルされたApacheと，この例題のために新規に作成したユーザアカウントで筆者が
実際に遭遇した問題である．

%Your web server may have per-user directories disabled.  If you're
%using Apache, search your config file for a \texttt{UserDir}
%directive.  If there's none present, per-user directories will be
%disabled.  If one exists, but its value is \texttt{disabled}, then
%per-user directories will be disabled.  Otherwise, the string after
%\texttt{UserDir} gives the name of the subdirectory that Apache will
%look in under your home directory, for example \dirname{public\_html}.

ウェブサーバはユーザ毎のディレクトリサービスを禁止されているかもしれない．
Apacheを使っている場合，設定ファイルの\texttt{UserDir}ディレクティブを
チェックする．もし存在しなければ，ユーザ毎のディレクトリサービスは禁止さ
れている．存在しても，値が\texttt{disabled}に設定されていれば，ユーザ毎の
ディレクトリサービスは禁止である．また，\texttt{UserDir}ディレクティブは
Apacheがサービス用に探すホームディレクトリ内のサブディレクトリを指定す
る．典型的な例は\dirname{public\_html}である．

%Your file access permissions may be too restrictive.  The web server
%must be able to traverse your home directory and directories under
%your \dirname{public\_html} directory, and read files under the latter
%too.  Here's a quick recipe to help you to make your permissions more
%appropriate.
ファイルアクセスパーミッションがきつすぎる．ウェブサーバはホームディレク
トリと\dirname{public\_html}内のディレクトリを渡ってファイルを読めなけれ
ばならない．パーミッションを適切に設定するには例えば次のようにすればよい．
\begin{codesample2}
  chmod 755 ~
  find ~/public_html -type d -print0 | xargs -0r chmod 755
  find ~/public_html -type f -print0 | xargs -0r chmod 644
\end{codesample2}

%The other possibility with permissions is that you might get a
%completely empty window when you try to load the script.  In this
%case, it's likely that your access permissions are \emph{too
%  permissive}.  Apache's \texttt{suexec} subsystem won't execute a
%script that's group-~or world-writable, for example.

パーミッションに関するその他の可能性として，スクリプトをロードしようとす
ると空のウィンドウが表示される問題がある．この場合は，パーミッション設定
が\emph{緩すぎる}可能性が高い．例えばApacheの\texttt{suexec}サブシステム
は，グループや全世界から書き込みのできるスクリプトを実行しない．

%Your web server may be configured to disallow execution of CGI
%programs in your per-user web directory.  Here's Apache's
%default per-user configuration from my Fedora system.
ウェブサーバはCGIプログラムの実行を禁止するように設定されているかもしれ
ない．著者のFedoraシステムから，Apacheのユーザ毎のデフォルト設定を例とし
て示す．
\begin{codesample2}
  <Directory /home/*/public_html>
      AllowOverride FileInfo AuthConfig Limit
      Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
      <Limit GET POST OPTIONS>
          Order allow,deny
          Allow from all
      </Limit>
      <LimitExcept GET POST OPTIONS>
          Order deny,allow
          Deny from all
      </LimitExcept>
  </Directory>
\end{codesample2}
%If you find a similar-looking \texttt{Directory} group in your Apache
%configuration, the directive to look at inside it is \texttt{Options}.
%Add \texttt{ExecCGI} to the end of this list if it's missing, and
%restart the web server.

Apache設定の中に同様の\texttt{Directory}グループがある場合，その中で注目
すべきディレクティブは\texttt{Options}である． \texttt{ExecCGI}がリストに
無ければ最後に追加し，ウェブサーバを再起動する．

%If you find that Apache serves you the text of the CGI script instead
%of executing it, you may need to either uncomment (if already present)
%or add a directive like this.
ApacheがCGIスクリプトを実行するのではなく，スクリプト自体のテキストを送っ
てくる場合は，以下のディレクティブを追加する．ディレクティブがすでにあり，
コメントアウトされているのなら，有効化する．
\begin{codesample2}
  AddHandler cgi-script .cgi
\end{codesample2}

%The next possibility is that you might be served with a colourful
%Python backtrace claiming that it can't import a
%\texttt{mercurial}-related module.  This is actually progress!  The
%server is now capable of executing your CGI script.  This error is
%only likely to occur if you're running a private installation of
%Mercurial, instead of a system-wide version.  Remember that the web
%server runs the CGI program without any of the environment variables
%that you take for granted in an interactive session.  If this error
%happens to you, edit your copy of \sfilename{hgweb.cgi} and follow the
%directions inside it to correctly set your \envar{PYTHONPATH}
%environment variable.

次の可能性は\texttt{mercurial}に関連したmoduleがインポートできないことを
警告するカラフルなPythonバックトレースが見えることだ．これは前進と言え
る．サーバはCGIスクリプトを実行できるようになった．このエラーはMercurial
をシステムワイドにインストールするのではなく，プライベートインストールし
た場合にのみ起きる．対話的なセッションとは異なり，ウェブサーバはCGIプログ
ラムを環境変数なしで起動する．このエラーが起きた場合は
\sfilename{hgweb.cgi}を編集し，環境変数\envar{PYTHONPATH}がセットされるよ
うにする．

%Finally, you are \emph{certain} to by served with another colourful
%Python backtrace: this one will complain that it can't find
%\dirname{/path/to/repository}.  Edit your \sfilename{hgweb.cgi} script
%and replace the \dirname{/path/to/repository} string with the complete
%path to the repository you want to serve up.

今度は\emph{おそらく}カラフルなPythonのバックトレースが見えるはずだ．これ
は\dirname{/path/to/repository}が見つからないことを警告している．
\sfilename{hgweb.cgi}スクリプトを編集し，\dirname{/path/to/repository}と
いう文字列を，サービスしたいリポジトリへの完全なパスに置き換える．

%At this point, when you try to reload the page, you should be
%presented with a nice HTML view of your repository's history.  Whew!

ここでページをリロードすると，リポジトリの履歴を表す美しいHTMLが見えるは
ずだ．やった！

%\subsubsection{Configuring lighttpd}
\subsubsection{lighttpdの設定}

%To be exhaustive in my experiments, I tried configuring the
%increasingly popular \texttt{lighttpd} web server to serve the same
%repository as I described with Apache above.  I had already overcome
%all of the problems I outlined with Apache, many of which are not
%server-specific.  As a result, I was fairly sure that my file and
%directory permissions were good, and that my \sfilename{hgweb.cgi}
%script was properly edited.

筆者の実験の中では，Apacheを使ってサービスしたのと同じリポジトリを人気を
獲得しつつあるウェブサーバである\texttt{lighttpd}を用いてサービスすること
も試みた． Apacheに関する全ての問題点を既に解決していたが，その中の多くは
サーバ特有というわけではなかった．結果として，ファイルとディレクトリのパー
ミッション設定が正しいこと， \sfilename{hgweb.cgi}スクリプトが正しく設定
されていることを確信した．

%Once I had Apache running, getting \texttt{lighttpd} to serve the
%repository was a snap (in other words, even if you're trying to use
%\texttt{lighttpd}, you should read the Apache section).  I first had
%to edit the \texttt{mod\_access} section of its config file to enable
%\texttt{mod\_cgi} and \texttt{mod\_userdir}, both of which were
%disabled by default on my system.  I then added a few lines to the end
%of the config file, to configure these modules.
すでにApacheを使っていたので，\texttt{lighttpd}でリポジトリのサービスを行
うことはたやすかった．（これは\texttt{lighttpd}を使ってサービスを試みる場
合もApacheのセクションを読む必要があるということでもある．）筆者のシステ
ムでは\texttt{mod\_cgi}と\texttt{mod\_userdir}が共に無効に設定されていた
ので，これらを有効にするために，まず設定ファイルの\texttt{mod\_access}セ
クションを編集する必要があった．その後で，下記のモジュールを有効にするた
めに，設定ファイルの末尾に数行を追加した．
\begin{codesample2}
  userdir.path = "public_html"
  cgi.assign = ( ".cgi" => "" )
\end{codesample2}
%With this done, \texttt{lighttpd} ran immediately for me.  If I had
%configured \texttt{lighttpd} before Apache, I'd almost certainly have
%run into many of the same system-level configuration problems as I did
%with Apache.  However, I found \texttt{lighttpd} to be noticeably
%easier to configure than Apache, even though I've used Apache for over
%a decade, and this was my first exposure to \texttt{lighttpd}.
これらの設定をするだけで\texttt{lighttpd}はすぐに動作した． Apacheより前
に\texttt{lighttpd}を試していたら，Apacheで直面したような様々なシステムレ
ベルの設定問題に遭遇していたに違いないが，初めて使う\texttt{lighttpd}の設
定の方が，これまで10年以上にわたって使ってきたApacheのそれよりも明らかに
簡単であることが分かった．

%\subsection{Sharing multiple repositories with one CGI script}
\subsection{1つのCGIスクリプトで複数のリポジトリを共有する}

%The \sfilename{hgweb.cgi} script only lets you publish a single
%repository, which is an annoying restriction.  If you want to publish
%more than one without wracking yourself with multiple copies of the
%same script, each with different names, a better choice is to use the
%\sfilename{hgwebdir.cgi} script.
\sfilename{hgweb.cgi}スクリプトには，1つのリポジトリしか公開できないとい
う厄介な制限がある． 2つ以上のリポジトリを公開したい場合は，同じスクリプ
トを別の名前でいくつも動かすのではなく， \sfilename{hgwebdir.cgi}スクリプ
トを使うのが良いだろう．

%The procedure to configure \sfilename{hgwebdir.cgi} is only a little
%more involved than for \sfilename{hgweb.cgi}.  First, you must obtain
%a copy of the script.  If you don't have one handy, you can download a
%copy from the master Mercurial repository at
%\url{http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi}.
\sfilename{hgwebdir.cgi}の設定の手順は\sfilename{hgweb.cgi}よりもわずかに
込み入っているだけだ．手近なところにスクリプトがなければ，Mercurialのマス
ターリポジトリ
\url{http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi}からスクリ
プトを入手できる．

%You'll need to copy this script into your \dirname{public\_html}
%directory, and ensure that it's executable.
このスクリプトを\dirname{public\_html}ディレクトリにコピーし，実行パーミッ
ションを与える．
\begin{codesample2}
  cp .../hgwebdir.cgi ~/public_html
  chmod 755 ~/public_html ~/public_html/hgwebdir.cgi
\end{codesample2}
%With basic configuration out of the way, try to visit
%\url{http://myhostname/~myuser/hgwebdir.cgi} in your browser.  It
%should display an empty list of repositories.  If you get a blank
%window or error message, try walking through the list of potential
%problems in section~\ref{sec:collab:wtf}.
通常の設定の場合，ブラウザで\url{http://myhostname/~myuser/hgwebdir.cgi}
を開くと，中身が空のリポジトリを表示するはずだ．ウィンドウ自体が空だった
り，エラーメッセージが表示される場合は，セクション~\ref{sec:collab:wtf}
の問題リストを参照してほしい．

%The \sfilename{hgwebdir.cgi} script relies on an external
%configuration file.  By default, it searches for a file named
%\sfilename{hgweb.config} in the same directory as itself.  You'll need
%to create this file, and make it world-readable.  The format of the
%file is similar to a Windows ``ini'' file, as understood by Python's
%\texttt{ConfigParser}~\cite{web:configparser} module.
\sfilename{hgwebdir.cgi}は外部の設定ファイルを使用している．デフォルトで
は同じディレクトリ内の\sfilename{hgweb.config}というファイルを参照する．
このファイルを作成し，全てのユーザから読めるように設定する．
このファイルはPythonの\texttt{ConfigParser}~\cite{web:configparser}で処
理できるようWindowsの``ini''ファイルと似た形式になっている．

%The easiest way to configure \sfilename{hgwebdir.cgi} is with a
%section named \texttt{collections}.  This will automatically publish
%\emph{every} repository under the directories you name.  The section
%should look like this:
\sfilename{hgwebdir.cgi}の最も簡単な設定方法は，\texttt{collections}セク
ションを編集することである．これは自動的に指定したディレクトリ以下の
\emph{全ての}リポジトリを公開する．このセクションは次のようになっている：
\begin{codesample2}
  [collections]
  /my/root = /my/root
\end{codesample2}
%Mercurial interprets this by looking at the directory name on the
%\emph{right} hand side of the ``\texttt{=}'' sign; finding
%repositories in that directory hierarchy; and using the text on the
%\emph{left} to strip off matching text from the names it will actually
%list in the web interface.  The remaining component of a path after
%this stripping has occurred is called a ``virtual path''.
Mercurialは``\texttt{=}''記号の\emph{右側}のディレクトリ名を参照して，ディ
レクトリ階層内のリポジトリを探す．見つかった時は，リポジトリのパスから
\emph{左側}の文字列とマッチする部分を削り，実際にウェブインタフェースに表
示されるパス文字列を作る．削除後のパスを``仮想パス''と呼ぶ．

%Given the example above, if we have a repository whose local path is
%\dirname{/my/root/this/repo}, the CGI script will strip the leading
%\dirname{/my/root} from the name, and publish the repository with a
%virtual path of \dirname{this/repo}.  If the base URL for our CGI
%script is \url{http://myhostname/~myuser/hgwebdir.cgi}, the complete
%URL for that repository will be
%\url{http://myhostname/~myuser/hgwebdir.cgi/this/repo}.
上の例で，CGIスクリプトは，ローカルパスが\dirname{/my/root/this/repo}であ
るリポジトリに対して\dirname{/my/root}を取り除き，\dirname{this/repo}とい
う仮想パスを作成し，公開する．もしCGIスクリプトのベースURLが
\url{http://myhostname/~myuser/hgwebdir.cgi}だとすると，リポジトリの完全
なURLは\url{http://myhostname/~myuser/hgwebdir.cgi/this/repo}となる．

%If we replace \dirname{/my/root} on the left hand side of this example
%with \dirname{/my}, then \sfilename{hgwebdir.cgi} will only strip off
%\dirname{/my} from the repository name, and will give us a virtual
%path of \dirname{root/this/repo} instead of \dirname{this/repo}.
この例の左辺の\dirname{/my/root}を\dirname{/my}で置き換えると
\sfilename{hgwebdir.cgi}は\dirname{/my}だけをリポジトリ名から取り除き，仮
想パスとして\dirname{this/repo}ではなく\dirname{root/this/repo}を作る．

%The \sfilename{hgwebdir.cgi} script will recursively search each
%directory listed in the \texttt{collections} section of its
%configuration file, but it will \texttt{not} recurse into the
%repositories it finds.
\sfilename{hgwebdir.cgi}スクリプトは，設定ファイルの\texttt{collections}
セクションに書かれたディレクトリを再帰的にサーチする．このスクリプトは見
つけたリポジトリの中はサーチ\texttt{しない}．

%The \texttt{collections} mechanism makes it easy to publish many
%repositories in a ``fire and forget'' manner.  You only need to set up
%the CGI script and configuration file one time.  Afterwards, you can
%publish or unpublish a repository at any time by simply moving it
%into, or out of, the directory hierarchy in which you've configured
%\sfilename{hgwebdir.cgi} to look.
\texttt{collections}メカニズムによって複数のリポジトリを簡単に公開するこ
とができる．CGIスクリプトと設定ファイルを編集するのは最初の一回だけでよ
く，リポジトリを\sfilename{hgwebdir.cgi}の探索するディレクトリ階層内に移
動すれば公開に，階層内から外せば非公開に設定できる．


%\subsubsection{Explicitly specifying which repositories to publish}
\subsubsection{どのリポジトリを表示するか明示的に指定する}

%In addition to the \texttt{collections} mechanism, the
%\sfilename{hgwebdir.cgi} script allows you to publish a specific list
%of repositories.  To do so, create a \texttt{paths} section, with
%contents of the following form.
\sfilename{hgwebdir.cgi}スクリプトは\texttt{collections}のメカニズムの他
にもリポジトリの特定のリストを公開する方法を用意している．下記のような
内容の\texttt{paths}セクションを作る．
\begin{codesample2}
  [paths]
  repo1 = /my/path/to/some/repo
  repo2 = /some/path/to/another
\end{codesample2}
%In this case, the virtual path (the component that will appear in a
%URL) is on the left hand side of each definition, while the path to
%the repository is on the right.  Notice that there does not need to be
%any relationship between the virtual path you choose and the location
%of a repository in your filesystem.
この場合，各々の定義の左辺に仮想パス（URLに現れる要素）が，リポジトリへの
パスが右辺に現れる．選んだ仮想パスとファイルシステム中での位置の間にはい
かなる関連性も必要ない．

%If you wish, you can use both the \texttt{collections} and
%\texttt{paths} mechanisms simultaneously in a single configuration
%file.
\texttt{collections}と\texttt{paths}の両方の機構を同一の設定ファイル内で
同時に用いることもできる．

%\begin{note}
%Beware duplicate virtual paths

%If several repositories have the same virtual path,
%\sfilename{hgwebdir.cgi} will not report an error.  Instead, it will
%behave unpredictably.
%\end{note}

\begin{note}
仮想パスの重複に注意

複数のリポジトリが同じ仮想パスを持つ場合でも\sfilename{hgwebdir.cgi}はエラー
を表示しないが，挙動は予測のつかないものとなる．
\end{note}

%\subsection{Downloading source archives}
\subsection{ソースアーカイブのダウンロード}

%Mercurial's web interface lets users download an archive of any
%revision.  This archive will contain a snapshot of the working
%directory as of that revision, but it will not contain a copy of the
%repository data.
ユーザはMercurialのウェブインタフェースからどのリビジョンのアーカイブも
ダウンロードすることができる．アーカイブは当該リビジョンのワーキングディ
レクトリのスナップショットを含むが，リポジトリ自体のデータは含まない．

%By default, this feature is not enabled.  To enable it, you'll need to
%add an \rcitem{web}{allow\_archive} item to the \rcsection{web}
%section of your \hgrc; see below for details.

デフォルトではこの機能は無効にされている．有効にするには
\rcitem{web}{allow\_archive}項目を\hgrc の\rcsection{web}セクションに追
加する必要がある．（詳細については下記を参照．）

%\subsection{Web configuration options}
\subsection{Web設定オプション}

%Mercurial's web interfaces (the \hgcmd{serve} command, and the
%\sfilename{hgweb.cgi} and \sfilename{hgwebdir.cgi} scripts) have a
%number of configuration options that you can set.  These belong in a
%section named \rcsection{web}.
Mercurialウェブインタフェース(the \hgcmd{serve}コマン
ド，\sfilename{hgweb.cgi}および\sfilename{hgwebdir.cgi}スクリプト)には多
くの設定オプションがある．これらは\rcsection{web}セクションに含まれる．

\begin{itemize}
%\item[\rcitem{web}{allow\_archive}] Determines which (if any) archive
%  download mechanisms Mercurial supports.  If you enable this
%  feature, users of the web interface will be able to download an
%  archive of whatever revision of a repository they are viewing.
%  To enable the archive feature, this item must take the form of a
%  sequence of words drawn from the list below.
\item[\rcitem{web}{allow\_archive}] どのアーカイブダウンロードメカニズム
	     をMercurialがサポートするのかを決定する．この機能を有効にす
	     ると，ウェブインタフェースのユーザはリポジトリの任意のリビジョ
	     ンのアーカイブをダウンロードできるようになる．アーカイブ昨
	     日を有効にするにはこの項目は，下のリストに示す語から構成さ
	     れなければならない．

  \begin{itemize}
%  \item[\texttt{bz2}] A \command{tar} archive, compressed using
%    \texttt{bzip2} compression.  This has the best compression ratio,
%    but uses the most CPU time on the server.
\item[\texttt{bz2}] \texttt{bzip2}圧縮された\command{tar}アーカイブ．圧縮率が最
	     も高いが，サーバのCPU時間も一番使用する．

%  \item[\texttt{gz}] A \command{tar} archive, compressed using
%    \texttt{gzip} compression.
\item[\texttt{gz}] \texttt{gzip}圧縮された\command{tar}アーカイブ．

%  \item[\texttt{zip}] A \command{zip} archive, compressed using LZW
%    compression.  This format has the worst compression ratio, but is
%    widely used in the Windows world.
\item[\texttt{zip}] LZW圧縮された\command{zip}アーカイブ．この中で圧縮率
	     は最低だが，Windowsの環境では広く用いられている．
  \end{itemize}

%  If you provide an empty list, or don't have an
%  \rcitem{web}{allow\_archive} entry at all, this feature will be
%  disabled.  Here is an example of how to enable all three supported
%  formats.
空のリストを与えるか，\rcitem{web}{allow\_archive}を記述しなければ，この
	     昨日は無効化される．サポートされている3つのフォーマット全て
	     を有効にする例を示す．
  \begin{codesample4}
    [web]
    allow_archive = bz2 gz zip
  \end{codesample4}

%\item[\rcitem{web}{allowpull}] Boolean.  Determines whether the web
%  interface allows remote users to \hgcmd{pull} and \hgcmd{clone} this
%  repository over~HTTP.  If set to \texttt{no} or \texttt{false}, only
%  the ``human-oriented'' portion of the web interface is available.
\item[\rcitem{web}{allowpull}] ブール値．リモートユーザにウェブインタフェー
	     スを用いた~HTTPによる\hgcmd{pull}及び\hgcmd{clone}を許可す
	     るかどうかを決める．\texttt{no}または\texttt{false}の場合，
	     ウェブインタフェースはブラウザによる閲覧のみが可能になる．

%\item[\rcitem{web}{contact}] String.  A free-form (but preferably
%  brief) string identifying the person or group in charge of the
%  repository.  This often contains the name and email address of a
%  person or mailing list.  It often makes sense to place this entry in
%  a repository's own \sfilename{.hg/hgrc} file, but it can make sense
%  to use in a global \hgrc\ if every repository has a single
%  maintainer.
\item[\rcitem{web}{contact}] 文字列．自由形式（簡潔な表記が好ましい）でリ
	     ポジトリを担当する人物やグループを記述する．通常は人名と，個
	     人またはメーリングリストのアドレスを含む．多くの場
	     合，\sfilename{.hg/hgrc}にこの記述を置くのが良い．もし全ての
	     リポジトリを同一人物が管理するのであれば，グローバルな
	     \hgrc\ に置くのもよい．

%\item[\rcitem{web}{maxchanges}] Integer.  The default maximum number
%  of changesets to display in a single page of output.
\item[\rcitem{web}{maxchanges}] 整数．1ページに表示するチェンジセットの
	     デフォルトの最大数．

%\item[\rcitem{web}{maxfiles}] Integer.  The default maximum number
%  of modified files to display in a single page of output.
\item[\rcitem{web}{maxfiles}] 整数．1ページに表示する更新されたファイル
	     のデフォルトの最大数．

%\item[\rcitem{web}{stripes}] Integer.  If the web interface displays
%  alternating ``stripes'' to make it easier to visually align rows
%  when you are looking at a table, this number controls the number of
%  rows in each stripe.
\item[\rcitem{web}{stripes}] 整数．表の表示を行う際に，行を見易くするため
	     ウェブインタフェースが交互に``ストライプ''表示する場合，この
	     値でそれぞれのストライプの行数を設定する．

%\item[\rcitem{web}{style}] Controls the template Mercurial uses to
%	     display the web interface.  Mercurial ships with several web
%	     templates.
%
%	     \begin{itemize}
%	      \item \texttt{coal} is monochromatic.
%	      \item \texttt{gitweb} emulates the visual style of git's
%		    web interface.
%	      \item \texttt{monoblue} uses solid blues and greys.
%	      \item \texttt{paper} is the default.
%	      \item \texttt{spartan} was the default for a long time.
%	     \end{itemize}
%
%	     You can also specify a custom template of your own; see
%	     chapter~\ref{chap:template} for details.  Here, you can see
%	     how to enable the \texttt{gitweb} style.

\item[\rcitem{web}{style}] Mercurialがウェブインターフェースを表示するた
	     めに使用するテンプレートを制御する．Mercurialにはいくつかの
	     ウェブテンプレートが同梱されている．

	     \begin{itemize}
	      \item \texttt{coal} 単色のテンプレート．
	      \item \texttt{gitweb} gitのウェブインターフェースを模倣し
		    たデザインのもの．
	      \item \texttt{monoblue} 単色の青とグレー．
	      \item \texttt{paper} デフォルト
	      \item \texttt{spartan} これまで長らくデフォルトとして使わ
		    れてきたもの．
	     \end{itemize}

	     独自のテンプレートを指定することも可能である．詳細
	     は~\ref{chap:template}を参照のこと．ここでは\texttt{gitweb}ス
	     タイルを有効にする方法を示す．
  \begin{codesample4}
    [web]
    style = gitweb
  \end{codesample4}
%\item[\rcitem{web}{templates}] Path.  The directory in which to search
%  for template files.  By default, Mercurial searches in the directory
%  in which it was installed.
\item[\rcitem{web}{templates}] パス．テンプレートファイルを検索するディレ
	     クトリ．デフォルトではMercurialはインストールされたディレク
	     トリからテンプレートを探す．
\end{itemize}
%If you are using \sfilename{hgwebdir.cgi}, you can place a few
%configuration items in a \rcsection{web} section of the
%\sfilename{hgweb.config} file instead of a \hgrc\ file, for
%convenience.  These items are \rcitem{web}{motd} and
%\rcitem{web}{style}.
\sfilename{hgwebdir.cgi}を利用する場合，便利のため，\hgrc\ ファイルではなく
\sfilename{hgweb.config}ファイルの\rcsection{web}セクションに\rcitem{web}{motd}および\rcitem{web}{style}項目を置くことができる．

%\subsubsection{Options specific to an individual repository}
\subsubsection{個々のリポジトリに特有のオプション}

%A few \rcsection{web} configuration items ought to be placed in a
%repository's local \sfilename{.hg/hgrc}, rather than a user's or
%global \hgrc.
いくつかの\rcsection{web} 設定項目はユーザやグローバルの \hgrc ではなく，
リポジトリローカルの\sfilename{.hg/hgrc}ファイルに書かれるのが自然である．
\begin{itemize}
%\item[\rcitem{web}{description}] String.  A free-form (but preferably
%  brief) string that describes the contents or purpose of the
%  repository.
\item[\rcitem{web}{description}] 文字列．リポジトリの内容や目的について
	     の説明．形式は自由だが，簡潔なものが好まれる．
%\item[\rcitem{web}{name}] String.  The name to use for the repository
%  in the web interface.  This overrides the default name, which is the
%  last component of the repository's path.
\item[\rcitem{web}{name}] 文字列．ウェブインタフェースでのリポジトリ名．
	     この名前はリポジトリパス中の最後の要素から作られるデフォルト
	     名をオーバライドする．
\end{itemize}

%\subsubsection{Options specific to the \hgcmd{serve} command}
\subsubsection{\hgcmd{serve}コマンド特有のオプション}

%Some of the items in the \rcsection{web} section of a \hgrc\ file are
%only for use with the \hgcmd{serve} command.
\hgrc\ ファイルの\rcsection{web}セクションの項目は\hgcmd{serve}コマンド
でのみ用いられる．

\begin{itemize}
%\item[\rcitem{web}{accesslog}] Path.  The name of a file into which to
%  write an access log.  By default, the \hgcmd{serve} command writes
%  this information to standard output, not to a file.  Log entries are
%  written in the standard ``combined'' file format used by almost all
%  web servers.
\item[\rcitem{web}{accesslog}] パス．アクセスログを出力するファイルの名
	     前．デフォルトでは\hgcmd{serve}コマンドはファイルではなく標
	     準出力へ出力を行う．ログエントリはほとんどのウェブサーバで
	     標準のコンバインドファイル形式で行われる．

%\item[\rcitem{web}{address}] String.  The local address on which the
%  server should listen for incoming connections.  By default, the
%  server listens on all addresses.
\item[\rcitem{web}{address}] 文字列．接続に対してサーバが待機するローカ
	     ルアドレス．デフォルトでは全てのアドレスに対して待機する．

%\item[\rcitem{web}{errorlog}] Path.  The name of a file into which to
%  write an error log.  By default, the \hgcmd{serve} command writes this
%  information to standard error, not to a file.
\item[\rcitem{web}{errorlog}] パス．エラーを記録するファイルの名前．デフォ
	     ルトでは \hgcmd{serve}コマンドはファイルではなく標準エラー
	     出力へ出力を行う．

%\item[\rcitem{web}{ipv6}] Boolean.  Whether to use the IPv6 protocol.
%  By default, IPv6 is not used.
\item[\rcitem{web}{ipv6}] ブール値．IPv6プロトコル利用の有無．デフォルト
	     はIPv6不使用．

%\item[\rcitem{web}{port}] Integer.  The TCP~port number on which the
%  server should listen.  The default port number used is~8000.
\item[\rcitem{web}{port}] 整数．サーバが待機するTCPポート番号．デフォル
	     トは8000番.

\end{itemize}

%\subsubsection{Choosing the right \hgrc\ file to add \rcsection{web}
  %items to}
\subsubsection{\rcsection{web}アイテムを追加する正しい\hgrc ファイルを選ぶ}

%It is important to remember that a web server like Apache or
%\texttt{lighttpd} will run under a user~ID that is different to yours.
%CGI scripts run by your server, such as \sfilename{hgweb.cgi}, will
%usually also run under that user~ID.

Apacheや\texttt{lighttpd}のようなウェブサーバは独自のユーザ~IDで動作する
ことに留意する必要がある．\sfilename{hgweb.cgi}のようなCGIスクリプトは通
常サーバがサーバのユーザ~IDで動作させる．

%If you add \rcsection{web} items to your own personal \hgrc\ file, CGI
%scripts won't read that \hgrc\ file.  Those settings will thus only
%affect the behaviour of the \hgcmd{serve} command when you run it.  To
%cause CGI scripts to see your settings, either create a \hgrc\ file in
%the home directory of the user ID that runs your web server, or add
%those settings to a system-wide \hgrc\ file.

\rcsection{web}アイテムをユーザ個人の\hgrc\ ファイルに追加してもCGIスクリ
プトはその\hgrc\ を参照しない．これらの設定は，ユーザが起動する
\hgcmd{serve}コマンドにのみ影響を与える．あなたが行った設定をCGIスクリプ
トから参照させるためには，ウェブサーバを起動するユーザIDのホームディレク
トリに\hgrc\ ファイルを作り，設定をシステムの\hgrc\ ファイルにも追加する
必要がある．

%\section{System-wide configuration}
\section{システムワイドの設定}

%On Unix-like systems shared by multiple users (such as a server to which
%people publish changes), it often makes sense to set up some global
%default behaviors, such as what theme to use in web interfaces.

複数のユーザが使用するUnix系のシステム（ユーザが変更を公開するサーバな
ど）では，ウェブインタフェースで使用するテーマのように，システム全体での
デフォルトの挙動を定義するとよい場合がある．

%If a file named \filename{/etc/mercurial/hgrc} exists, Mercurial will
%read it at startup time and apply any configuration settings it finds in
%that file.  It will also look for files ending in a \texttt{.rc}
%extension in a directory named \filename{/etc/mercurial/hgrc.d}, and
%apply any configuration settings it finds in each of those files.

\filename{/etc/mercurial/hgrc}というファイルがあると，Mercurialは起動時に
これを読み，全ての設定を適用する．また，\filename{/etc/mercurial/hgrc.d}
ディレクトリ内のファイル名が\texttt{.rc}で終るファイルを探し，書かれた設
定を適用する．

%\subsection{Making Mercurial more trusting}
\subsection{Mercurialの信頼性を上げる}

%One situation in which a global \filename{hgrc} can be useful is if
%users are pulling changes owned by other users.  By default, Mercurial
%will not trust most of the configuration items in a \filename{.hg/hgrc}
%file inside a repository that is owned by a different user. If we clone
%or pull changes from such a repository, Mercurial will print a warning
%stating that it does not trust their \filename{.hg/hgrc}.

システム全体の\filename{hgrc}ファイルが有用な場合の一例に，他のユーザが所
有するリポジトリからpullする場合がある．デフォルトではMercurialは別のユー
ザの所有するリポジトリ内にある\filename{.hg/hgrc}ファイルのほとんどの項目
を信頼しない．そのようなリポジトリからクローンや変更のpullを行う
と，Mercurialは\filename{.hg/hgrc}を信頼しないという警告を表示する．

%If everyone in a particular Unix group is on the same team and
%\emph{should} trust each other's configuration settings, or we want to
%trust particular users, we can override Mercurial's skeptical defaults
%by creating a system-wide \filename{hgrc} file such as the following:

Unixで特定のグループに入っているユーザ全てが同じチームに属し，互いに他の
ユーザの設定を信頼\emph{すべき}場合や，特定のユーザたちの設定を信頼すべき
場合は，次のようなシステム全体の\filename{hgrc}ファイルを作成
し，Mercurialの懐疑的な設定をオーバライドすることができる．

%\begin{codesample2}
%# Save this as e.g. /etc/mercurial/hgrc.d/trust.rc
%[trusted]
%# Trust all entries in any hgrc file owned by the "editors" or
%# "www-data" groups.
%groups = editors, www-data
%
%# Trust entries in hgrc files owned by the following users.
%users = apache, bobo
%\end{codesample2}

\begin{codesample2}
# この内容を /etc/mercurial/hgrc.d/trust.rc などとして保存する
[trusted]
# 所有者が "editors" または "www-data" である hgrc ファイルを信頼する
groups = editors, www-data

# 次のユーザの所有する hgrc ファイルのエントリを信頼する
users = apache, bobo
\end{codesample2}

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