%\chapter{A tour of Mercurial: the basics}
\chapter{Mercurialツアー: 基本}
\label{chap:tour-basic}

%\section{Installing Mercurial on your system}
\section{システムへのMercurialのインストール}
\label{sec:tour:install}

%Prebuilt binary packages of Mercurial are available for every popular
%operating system.  These make it easy to start using Mercurial on your
%computer immediately.

人気の高いオペレーティングシステムではMercurialのビルド済みバイナリパッ
ケージが提供されている．これを用いれば読者の計算機の上で直ちにMercurial
を使うことができる．

\subsection{Windows}

%The best version of Mercurial for Windows is TortoiseHg, which can be
%found at \url{http://bitbucket.org/tortoisehg/stable/wiki/Home}. This
%package has no external dependencies; it ``just works''. It
%provides both command line and graphical user interfaces.

Windows向けMercurialの最も優れたバージョンであるTortoiseHgは，
\url{http://bitbucket.org/tortoisehg/stable/wiki/Home}で入手できる．
このパッケージは外部のパッケージへ依存せず，すぐに動作する．コマンドライ
ンインタフェースとグラフィカルユーザインタフェースの両方が利用できる．

\subsection{Mac OS X}

%Lee Cantey publishes an installer of Mercurial for Mac OS X at
%       \url{http://mercurial.berkwood.com}.

Lee CanteyはMac OS~X向けのMercurialインストーラを
\url{http://mercurial.berkwood.com}で配布している．

\subsection{Linux}
%Because each Linux distribution has its own packaging tools, policies,
%and rate of development, it's difficult to give a comprehensive set of
%instructions on how to install Mercurial binaries.  The version of
%Mercurial that you will end up with can vary depending on how active
%the person is who maintains the package for your distribution.

Linuxの各ディストリビューションはそれぞれ独自のパッケージツール，ポリ
シー，開発ペースを持っているため，全てを網羅してMercurialバイナリのインス
トール手順を述べることは困難である．それぞれのディストリビューションで利
用可能なMercurialのバージョンは，パッケージメンテナの活動に依存する．

%To keep things simple, I will focus on installing Mercurial from the
%command line under the most popular Linux distributions.  Most of
%these distributions provide graphical package managers that will let
%you install Mercurial with a single click; the package name to look
%for is \texttt{mercurial}.

単純化のために，大多数のLinuxディストリビューションでコマンドラインから
Mercurialをインストールする方法に限定して説明することにする．これらの大半
のディストリビューションでは，Mercurialをクリック1回でインストールできる
ようなグラフィカルなパッケージマネージャを用意している．

\begin{itemize}
\item[Debian and Ubuntu]
  \begin{codesample4}
    apt-get install mercurial
  \end{codesample4}

\item[Fedora and OpenSUSE]
  \begin{codesample4}
    yum install mercurial
  \end{codesample4}

\item[Gentoo]
  \begin{codesample4}
    emerge mercurial
  \end{codesample4}

%  The Ubuntu package for Mercurial tends to lag behind the Debian
%  version by a considerable time margin (at the time of writing, seven
%  months), which in some cases will mean that on Ubuntu, you may run
%  into problems that have since been fixed in the Debian package.
UbuntuのMercurialパッケージはDebianのものに比べて無視できないほどの遅れ
	     がある（これを書いている時点では7カ月）．このため，Ubuntuで
	     はDebianではすでに解決された問題に直面するかもしれない．
\end{itemize}

\subsection{Solaris}

%SunFreeWare, at \url{http://www.sunfreeware.com}, provides prebuilt
%packages of Mercurial.
\url{http://www.sunfreeware.com}からビルド済みのMercurialパッケージが入
手できる．

%\section{Getting started}
\section{Mercurialを使う}

%To begin, we'll use the \hgcmd{version} command to find out whether
%Mercurial is actually installed properly.  The actual version
%information that it prints isn't so important; it's whether it prints
%anything at all that we care about.
%\interaction{tour.version}

まず\hgcmd{version}コマンドでMercurialが実際に正しくインストールされたか
を確認してみよう．表示されるかどうかが問題であって，表示されるバージョン
情報は特に重要ではない．
\interaction{tour.version}

%\subsection{Built-in help}
\subsection{組み込みヘルプ}

%Mercurial provides a built-in help system.  This is invaluable for those
%times when you find yourself stuck trying to remember how to run a
%command.  If you are completely stuck, simply run \hgcmd{help}; it
%will print a brief list of commands, along with a description of what
%each does.  If you ask for help on a specific command (as below), it
%prints more detailed information.
%\interaction{tour.help}
%For a more impressive level of detail (which you won't usually need)
%run \hgcmdargs{help}{\hggopt{-v}}.  The \hggopt{-v} option is short
%for \hggopt{--verbose}, and tells Mercurial to print more information
%than it usually would.

Mercurialは組み込みのヘルプシステムを備えている．これはコマンドの使い方に
詰まった時に役に立つ．何を実行したら良いのか全く分からない場合は単に
\hgcmd{help}を実行する．これはコマンドの一部を説明と共にリスト表示する．
特定のコマンドについてヘルプが見たい場合は，下記のようにするとより詳細な
情報が得られる．
\interaction{tour.help}
通常必要としないような極めて詳しい説明が必要な場合は
\hgcmdargs{help}{\hggopt{-v}}を実行する．\hggopt{-v}は\hggopt{--verbose}
オプションの短縮形で，より詳細な情報を表示するオプションである．

%\section{Working with a repository}
\section{リポジトリを使った作業}

%In Mercurial, everything happens inside a \emph{repository}.  The
%repository for a project contains all of the files that ``belong to''
%that project, along with a historical record of the project's files.

Mercurialでは\emph{リポジトリ内}で一切が起きる．プロジェクトのリポジトリ
は所属する全てのファイルとそれらの履歴情報を持つ．

%There's nothing particularly magical about a repository; it is simply
%a directory tree in your filesystem that Mercurial treats as special.
%You can rename or delete a repository any time you like, using either the
%command line or your file browser.

リポジトリには特に不思議なところはない．リポジトリはMercurialが特別の扱い
をするだけのファイルシステム上の単なるディレクトリツリーにすぎない．
リポジトリはコマンドラインやファイルブラウザからいつでも名前を変えたり消
去することができる．

%\subsection{Making a local copy of a repository}
\subsection{リポジトリのローカルコピーを作る}

%\emph{Copying} a repository is just a little bit special.  While you
%could use a normal file copying command to make a copy of a
%repository, it's best to use a built-in command that Mercurial
%provides.  This command is called \hgcmd{clone}, because it makes an
%identical copy of an existing repository.
%\interaction{tour.clone}

リポジトリの\emph{コピー}はやや特殊である．通常のファイルコピーコマンドを
使ってリポジトリのコピーを作成することもできるが，Mercurialの組み込みコマ
ンドを使ってコピーするのが一番良い．このコマンドは\hgcmd{clone}と呼ばれ，
既存のリポジトリの完全なコピーを作成する．
\interaction{tour.clone}

%One advantage of using \hgcmd{clone} is that, as we can see above, it
%lets us clone repositories over the network.  Another is that it
%remembers where we cloned from, which we'll find useful soon when we
%want to fetch new changes from another repository.

\hgcmd{clone}コマンドを使う利点の一つは，上で見たようにリポジトリをネット
ワーク越しにクローンできる点である．またもう一点，このコマンドはどこから
クローンしたのかを記録するため，新たな変更を別のリポジトリから取得しよう
とする際に便利である．

%If our clone succeeded, we should now have a local directory called
%\dirname{hello}.  This directory will contain some files.
%\interaction{tour.ls}
%These files have the same contents and history in our repository as
%they do in the repository we cloned.

クローンが成功すると\dirname{hello}というローカルディレクトリができる．
このディレクトリにはオリジナルと同一のファイルが含まれる．
\interaction{tour.ls}
これらのファイルはクローンしたリポジトリ内と全く同じ内容と履歴を持ってい
る．

%Every Mercurial repository is complete, self-contained, and independent.
%It contains its own private copy of a project's files and history. As we
%just mentioned, A cloned repository remembers the location of the
%repository it was cloned from, but it does not communicate with that
%repository, or any other, unless you tell it to.

全てのMercurialリポジトリは完全かつ自己充足的で独立である．リポジトリはプ
ロジェクトに属すファイルのプライベートコピーと履歴を持つ．今述べたよう
に，クローンされたリポジトリはクローン元のリポジトリの場所を記憶している
が，ユーザが指示しない限り，そのリポジトリや他のリポジトリと通信を行うこ
とはない．

%What this means for now is that we're free to experiment with our
%repository, safe in the knowledge that it's a private ``sandbox'' that
%won't affect anyone else.

今の段階ではローカルなリポジトリとは外部へ何の影響も及ぼさないプライベー
トな``サンドボックス''で，この中でどんなことでも試すことができると解釈し
ておけば十分である．

%\subsection{What's in a repository?}
\subsection{リポジトリには何が含まれるか？}

%When we take a more detailed look inside a repository, we can see that
%it contains a directory named \dirname{.hg}.  This is where Mercurial
%keeps all of its metadata for the repository.
%\interaction{tour.ls-a}

リポジトリの内部をより詳しく見てみると，\dirname{.hg}というディレクトリ
があるのに気づく．Mercurialはここにリポジトリのためのメタデータを保管し
ている．
\interaction{tour.ls-a}

%The contents of the \dirname{.hg} directory and its subdirectories are
%private to Mercurial.  Every other file and directory in the
%repository is yours to do with as you please.

\dirname{.hg}ディレクトリの中身と，このディレクトリのサブディレクトリは
Mercurial専用のものである．リポジトリのそれ以外のファイルとディレクトリ
はユーザに属す．

%To introduce a little terminology, the \dirname{.hg} directory is the
%``real'' repository, and all of the files and directories that coexist
%with it are said to live in the \emph{working directory}.  An easy way
%to remember the distinction is that the \emph{repository} contains the
%\emph{history} of your project, while the \emph{working directory}
%contains a \emph{snapshot} of your project at a particular point in
%history.

ここで少々用語を定義しようと思う．\dirname{.hg}ディレクトリを``リアル''リ
ポジトリ，このディレクトリと一緒に扱われるファイルやディレクトリを
\emph{ワーキングディレクトリ}と呼ぶことにする．これらを簡単に区別するため
に，\emph{リポジトリ}はプロジェクトの\emph{履歴}を保存し，\emph{ワーキン
グディレクトリ}はプロジェクトの履歴の中のある時点の\emph{スナップショッ
ト}を持つと覚えると良い．

%\section{A tour through history}
\section{履歴を辿る}

%One of the first things we might want to do with a new, unfamiliar
%repository is understand its history.  The \hgcmd{log} command gives
%us a view of the history of changes in the repository.
%\interaction{tour.log}
%By default, this command prints a brief paragraph of output for each
%change to the project that was recorded.  In Mercurial terminology, we
%call each of these recorded events a \emph{changeset}, because it can
%contain a record of changes to several files.

未知のリポジトリに対してまずしようと思うことは，そのリポジトリでの変更の
履歴を知ることだろう．履歴は\hgcmd{log}コマンドで見ることができる．
\interaction{tour.log}
デフォルトでは，このコマンドはプロジェクトに対して行われた変更の各々につ
いて簡潔なパラグラフを表示する． Mercurialの用語では，履歴中の変更のイベ
ントを\emph{チェンジセット}と呼ぶ．その理由は，複数のファイルに対する変更
の記録を持ち得るからである．

%The fields in a record of output from \hgcmd{log} are as follows.
\hgcmd{log}から出力される記録の各フィールドは次のようになっている．
\begin{itemize}
%\item[\texttt{changeset}] This field has the format of a number,
%	     followed by a colon, followed by a hexadecimal (or
%	     \emph{hex}) string.  These are \emph{identifiers} for the
%	     changeset.  The hex string is a unique identifier: the same
%	     hex string will always refer to the same changeset. The
%	     number is shorter and easier to type than the hex string,
%	     but it isn't unique: the same number in two different
%	     clones of a repository may identify different changesets.
%	     Why provide the number at all, then?  For local
%	     convenience.
\item[\texttt{changeset}] 番号，それに続くコロンおよび16進文字列．これは
	     チェンジセットの\emph{識別子}である．16進文字列は固有の識別
	     子で，同一の識別子は常に同じチェンジセットを指す．番号は短く
	     入力も16進文字列より容易であるが，チェンジセットに固有ではな
	     い．同じ番号でもリポジトリの別のクローンでは，違うチェンジセッ
	     トを指す可能性がある．番号は単にローカルな利便のために提供さ
	     れている．
%\item[\texttt{user}] The identity of the person who created the
%  changeset.  This is a free-form field, but it most often contains a
%  person's name and email address.
 \item[\texttt{user}] チェンジセット作成者．このフィールドの書式は自由だ
	      が，ほとんどの場合氏名とemailアドレスである．
%\item[\texttt{date}] The date and time on which the changeset was
%  created, and the timezone in which it was created.  (The date and
%  time are local to that timezone; they display what time and date it
%  was for the person who created the changeset.)
 \item[\texttt{date}] チェンジセットが作成された日付と時刻およびタイムゾー
	      ン． （日時はチェンジセットの作成者の属すタイムゾーンにロー
	      カルである．）
%\item[\texttt{summary}] The first line of the text message that the
%  creator of the changeset entered to describe the changeset.
 \item[\texttt{summary}] テキストメッセージの最初の行はチェンジセットの説
	     明に入力されたチェンジセットの作成者である．
% \item Some changesets, such as the first in the list above, have a
%	     \texttt{tag} field.  A tag is another way to identify a
%	     changeset, by giving it an easy-to-remember name. (The tag
%	     named \texttt{tip} is special: it always refers to the
%	     newest change in a repository.)
 \item 上のリストの最初のチェンジセットのように\texttt{tag}フィールドを持
       つチェンジセットもある．タグはチェンジセットを識別するためのもう
       一つの方法で，覚えやすい名前を自由に付けることができる．（タグ
       \texttt{tip}は特別で，常にリポジトリの最新のチェンジセットを指す．）
\end{itemize}
%The default output printed by \hgcmd{log} is purely a summary; it is
%missing a lot of detail.
\hgcmd{log}のデフォルト出力は要約にすぎず，多くの詳細情報を欠いている．

%Figure~\ref{fig:tour-basic:history} provides a graphical representation of
%the history of the \dirname{hello} repository, to make it a little
%easier to see which direction history is ``flowing'' in.  We'll be
%returning to this figure several times in this chapter and the chapter
%that follows.

図~\ref{fig:tour-basic:history}は\dirname{hello}リポジトリの履歴をグラフ表
示したものである．この表示によってどの方向の履歴が順方向なのか理解しやす
くなっている．今後，この図を何度か参照する．

\begin{figure}[ht]
  \centering
  \grafix{tour-history}
%  \caption{Graphical history of the \dirname{hello} repository}
  \caption{\dirname{hello}リポジトリの履歴グラフ}
 \label{fig:tour-basic:history}
\end{figure}

%\subsection{Changesets, revisions, and talking to other people}
\subsection{チェンジセット, リビジョン, 他のユーザとのやりとり}

%As English is a notoriously sloppy language, and computer science has
%a hallowed history of terminological confusion (why use one term when
%four will do?), revision control has a variety of words and phrases
%that mean the same thing.  If you are talking about Mercurial history
%with other people, you will find that the word ``changeset'' is often
%compressed to ``change'' or (when written) ``cset'', and sometimes a
%changeset is referred to as a ``revision'' or a ``rev''.

英語はいい加減なことで悪名の高い言語であり，コンピュータサイエンスでは専
門用語の混乱が甚だしい．（4人が1つの用語を使うことなど有り得ない．）リビ
ジョンコントロールは沢山の同義語を持っている．他の人とMercurialの履歴につ
いて話すとき，``チェンジセット''がしばしば``チェンジ''に略されたり，書き
言葉では``cset''などとされたり，時にはチェンジセットが``リビジョン''や
``rev''と表されたりすることに気づくだろう．

%While it doesn't matter what \emph{word} you use to refer to the
%concept of ``a~changeset'', the \emph{identifier} that you use to
%refer to ``a~\emph{specific} changeset'' is of great importance.
%Recall that the \texttt{changeset} field in the output from
%\hgcmd{log} identifies a changeset using both a number and a
%hexadecimal string.

``a~changeset''というチェンジセットの\emph{呼び名}は自由だが，
``a~\emph{specific} changeset''を参照する\emph{識別子}は非常に重要である．
\hgcmd{log}コマンドの出力に含まれる\texttt{changeset}フィールドは，あるチェ
ンジセットを番号と16進文字列で表していたことを思い出して欲しい．

%\begin{itemize}
%\item The revision number is a handy notation that \emph{only valid in
%      that repository}.
%\item The hexadecimal string is the \emph{permanent, unchanging
%    identifier} that will always identify that exact changeset in
%  \emph{every} copy of the repository.
%\end{itemize}
\begin{itemize}
\item リビジョン番号は\emph{そのリポジトリに限って有効}な簡便記法である．
\item 16進文字列は\emph{永続的かつ不変の識別子}で，リポジトリのコピー
      \emph{全て}で常に特定のチェンジセットを示す．
\end{itemize}

%This distinction is important.  If you send someone an email talking
%about ``revision~33'', there's a high likelihood that their
%revision~33 will \emph{not be the same} as yours.  The reason for this
%is that a revision number depends on the order in which changes
%arrived in a repository, and there is no guarantee that the same
%changes will happen in the same order in different repositories.
%Three changes $a,b,c$ can easily appear in one repository as $0,1,2$,
%while in another as $0,2,1$.

この区別は重要である．誰かに``revision~33''と言った時，そのリビジョン33が
自分のリポジトリのリポジトリのものとは\emph{違うものである}可能性は高い．
その理由は，リビジョン番号はリポジトリに変更が現れた順序によって決ま
り，Mercurialでは別のリポジトリで同じ変更が同じ順序で起こる保証はないため
である． 3つの変更$a,b,c$は，あるリポジトリで$0,1,2$の順で起こり，別のリ
ポジトリでは$0,2,1$の順序で起こり得る．

%Mercurial uses revision numbers purely as a convenient shorthand.  If
%you need to discuss a changeset with someone, or make a record of a
%changeset for some other reason (for example, in a bug report), use
%the hexadecimal identifier.

Mercurialはリビジョン番号を単に便利のための略記法として用いる．誰かとチェ
ンジセットについて議論したり，（バグ報告などのために）チェンジセットを記
録したい場合は16進の識別子を利用すべきである．

%\subsection{Viewing specific revisions}
\subsection{特定のリビジョンを見る}

%To narrow the output of \hgcmd{log} down to a single revision, use the
%\hgopt{log}{-r} (or \hgopt{log}{--rev}) option.  You can use either a
%revision number or a hexadecimal changeset identifier, and you can
%provide as many revisions as you want.  \interaction{tour.log-r}

\hgcmd{log}の出力をある1つのリビジョンに制限するためには，
\hgopt{log}{-r}（または \hgopt{log}{--rev}）オプションを用いる．リビジョ
ン番号も16進文字列のチェンジセット識別子も利用可能であり，指定できるリビ
ジョンの数に制限はない．
\interaction{tour.log-r}

%If you want to see the history of several revisions without having to
%list each one, you can use \emph{range notation}; this lets you
%express the idea ``I want all revisions between $a$ and $b$,
%inclusive''.
%\interaction{tour.log.range}
%Mercurial also honours the order in which you specify revisions, so
%\hgcmdargs{log}{-r 2:4} prints $2,3,4$ while \hgcmdargs{log}{-r 4:2}
%prints $4,3,2$.

いくつかのリビジョンの履歴を，いちいちリビジョンを指定することなく見たい
時は，\emph{範囲記法}が使える．これにより``$a$から$b$までに含まれる全ての
リビジョン''を指定することができる．
\interaction{tour.log.range}
Mercurialはリビジョンが指定された順序を考慮する．\hgcmdargs{log}{-r 2:4}
は$2,3,4$の順に表示し，\hgcmdargs{log}{-r 4:2}は$4,3,2$の順に表示を行う．

%\subsection{More detailed information}
\subsection{より詳細な情報}

%While the summary information printed by \hgcmd{log} is useful if you
%already know what you're looking for, you may need to see a complete
%description of the change, or a list of the files changed, if you're
%trying to decide whether a changeset is the one you're looking for.
%The \hgcmd{log} command's \hggopt{-v} (or \hggopt{--verbose})
%option gives you this extra detail.
%\interaction{tour.log-v}

探しているものがはっきりしている場合は\hgcmd{log}コマンドによるサマリー情
報は有用だが，どのチェンジセットが見つけようとするチェンジセットなのか決
める時には変更の完全な記述や変更されたファイルのリストが必要になるかもし
れない．\hgcmd{log}コマンドの\hggopt{-v}（または\hggopt{--verbose}）オプ
ションでより詳細な情報を見ることができる．
\interaction{tour.log-v}

%If you want to see both the description and content of a change, add
%the \hgopt{log}{-p} (or \hgopt{log}{--patch}) option.  This displays
%the content of a change as a \emph{unified diff} (if you've never seen
%a unified diff before, see section~\ref{sec:mq:patch} for an overview).
%\interaction{tour.log-vp}

説明と変更の内容の両方を見たい場合は\hgopt{log}{-p}（または
\hgopt{log}{--patch}）オプションを追加する．このオプションは変更の内容を
\emph{unified diff}形式で表示する．（unified diff形式を見たことがなけれ
ば概略を\ref{sec:mq:patch}節で見ることができる．）
\interaction{tour.log-vp}

%The \hgopt{log}{-p} option is tremendously useful, so it's well worth
%remembering.

\hgopt{log}{-p}オプションは驚異的に便利なので覚えておくと良い．

%\section{All about command options}
\section{コマンドオプションのすべて}

%Let's take a brief break from exploring Mercurial commands to discuss
%a pattern in the way that they work; you may find this useful to keep
%in mind as we continue our tour.

Mercurialコマンドを試すのを一休みして，コマンドの動作パターンについて議
論してみよう．これはこのツアーを続ける上で役に立つだろう．

%Mercurial has a consistent and straightforward approach to dealing
%with the options that you can pass to commands.  It follows the
%conventions for options that are common to modern Linux and Unix
%systems.
Mercurialはコマンドにオプションを渡す際に一貫性のある直接的なアプローチを
取っている．これは現代のLinuxおよびUnixに共通のオプションに関する習慣に基
づいている．
\begin{itemize}
%\item Every option has a long name.  For example, as we've already
%  seen, the \hgcmd{log} command accepts a \hgopt{log}{--rev} option.
 \item 全てのオプションは長形式のオプションを持つ．例えば，すでに見ている
       ように\hgcmd{log}コマンドは\hgopt{log}{--rev}オプションを受け付け
       る．
%\item Most options have short names, too.  Instead of
%  \hgopt{log}{--rev}, we can use \hgopt{log}{-r}.  (The reason that
%  some options don't have short names is that the options in question
%  are rarely used.)
 \item ほとんどのオプションは短縮名を持つ．\hgopt{log}{--rev}オプションの
       代わりに\hgopt{log}{-r}が使える．（いくつかのオプションで短縮名が
       使えない理由は，そのオプションがほとんど使用されないためである．）
%\item Long options start with two dashes (e.g.~\hgopt{log}{--rev}),
%  while short options start with one (e.g.~\hgopt{log}{-r}).
 \item 長形式のオプションは2つのダッシュで始まる（例
       ~\hgopt{log}{--rev}）．一方短形式のオプションは1つのダッシュで始ま
       る（例 ~\hgopt{log}{-r}）．
%\item Option naming and usage is consistent across commands.  For
%  example, every command that lets you specify a changeset~ID or
%  revision number accepts both \hgopt{log}{-r} and \hgopt{log}{--rev}
%  arguments.
 \item オプションの命名と使用法はコマンド間で一貫している．例を挙げると，
       チェンジセットIDまたはリビジョン番号を指定させるコマンドの全てで
       \hgopt{log}{-r}と\hgopt{log}{--rev}の両方を受け付ける．
% \item If you are using short options, you can save typing by running
%       them together. For example, the command \hgopt{log}{-v -p -r 2}
%       can be written as \hgopt{log}{-vpr2}
 \item 短形式のオプションを使っている時はあ，複数のオプションを組み合わせ
       て入力の手間を省くことができる．例えば\hgopt{log}{-v -p -r 2}は
       \hgopt{log}{-vpr2}と書くことができる．
\end{itemize}
%In the examples throughout this book, I use short options instead of
%long.  This just reflects my own preference, so don't read anything
%significant into it.
この本の例の全てで短形式のオプションを用いる．これは単に筆者の好みのため
で，深い意味はない．

%Most commands that print output of some kind will print more output
%when passed a \hggopt{-v} (or \hggopt{--verbose}) option, and less
%when passed \hggopt{-q} (or \hggopt{--quiet}).
表示出力を行うほとんどのコマンドで\hggopt{-v}（または\hggopt{--verbose}）
オプションを付けるとより詳細な出力を行い，\hggopt{-q}（または
\hggopt{--quiet}）オプションを付けるとより簡潔な出力となる．

%\begin{note}
%Option naming consistency
%
%Almost always, Mercurial commands use consistent option names to refer
%to the same concepts.  For instance, if a command deals with changesets,
%you'll always identify them with \hgopt{log}{--rev} or \hgopt{log}{-r}

%This consistent use of option names makes it easier to remember what
%options a particular command takes.
%\end{note}

\begin{note}
オプション名の一貫性

Mercurialコマンドでは，同じ対象を扱う際，ほとんど常に同じオプション名を使
うようになっている．例を挙げると，チェンジセットを扱うコマンドの場合は常
に\hgopt{log}{--rev}や\hgopt{log}{-r}でチェンジセットの指定ができる．この
一貫性により，組まんどのオプションが覚えやすくなっている．
\end{note}

%\section{Making and reviewing changes}
\section{変更の仕方，変更のレビュー}

%Now that we have a grasp of viewing history in Mercurial, let's take a
%look at making some changes and examining them.

Mercurialで履歴を見る方法については理解した．ここでは何か変更を行って，
これを見てみよう．

%The first thing we'll do is isolate our experiment in a repository of
%its own.  We use the \hgcmd{clone} command, but we don't need to
%clone a copy of the remote repository.  Since we already have a copy
%of it locally, we can just clone that instead.  This is much faster
%than cloning over the network, and cloning a local repository uses
%less disk space in most cases, too.
%\begin{footnote}
%The saving of space arises when source and destination repositories are
%on the same filesystem, in which case Mercurial will use hardlinks to do
%copy-on-write sharing of its internal metadata.  If that explanation
%meant nothing to you, don't worry: everything happens transparently and
%automatically, and you don't need to understand it.
%\end{footnote}
%\interaction{tour.reclone}
%As an aside, it's often good practice to keep a ``pristine'' copy of a
%remote repository around, which you can then make temporary clones of
%to create sandboxes for each task you want to work on.  This lets you
%work on multiple tasks in parallel, each isolated from the others
%until it's complete and you're ready to integrate it back.  Because
%local clones are so cheap, there's almost no overhead to cloning and
%destroying repositories whenever you want.

まず最初にこの実験を本来のリポジトリから隔離するために\hgcmd{clone}を行
う．すでにローカルなリポジトリを持っているので，これをクローンするだけで
よく，リモートのリポジトリをコピーする必要はない．ローカルなクローンはネッ
トワーク越しに行うクローンよりもずっと速く，多くの場合使用するディスク容
量も少ない．
\begin{footnote}
同一ファイルシステム上でリポジトリのクローンを行う場合， Mercurialはハー
ドリンクを使い，内部メタデータをコピーオンライトで共有し，ディスク使用量
の節約を行う．この説明がよくわからなくても心配する必要はない．この動作は
すべて透過的かつ自動的に行われるため，気にする必要はない．
\end{footnote}
\interaction{tour.reclone}
また，何か作業をしたい時にサンドボックスとするために一時的なクローンを作
成し，リモートリポジトリのコピーを``清潔''に保つことはしばしば役に立つ．
これにより複数の作業を並行して行うことができ，かつ，作業が完了し，再び統
合するまで他の作業から隔離されたままにしておくことができる．リポジトリの
ローカルクローンはとても手軽で，クローンと廃棄にほとんどオーバヘッドがな
い．

%In our \dirname{my-hello} repository, we have a file
%\filename{hello.c} that contains the classic ``hello, world'' program.
%\interaction{tour.cat1}
\dirname{my-hello}リポジトリ内にはクラシックな``hello, world''プログラム
である\filename{hello.c}がある．
\interaction{tour.cat1}

%Let's edit this file so that it prints a second line of output.
%\interaction{tour.cat2}
このファイルを2行目が出力されるように編集する．
\interaction{tour.cat2}

%Mercurial's \hgcmd{status} command will tell us what Mercurial knows
%about the files in the repository.
%\interaction{tour.status}
%The \hgcmd{status} command prints no output for some files, but a line
%starting with ``\texttt{M}'' for \filename{hello.c}.  Unless you tell
%it to, \hgcmd{status} will not print any output for files that have
%not been modified.
リポジトリ内のファイルに対してMercurialが把握している内容を
\hgcmd{status}コマンドで見ることができる．
\interaction{tour.status}
\hgcmd{status}コマンドはいくつかのファイルに対しては出力を行わないが，
\filename{hello.c}に対して``\texttt{M}''を表示する．特に指示をしない場
合，\hgcmd{status}コマンドは変更されていないファイルに対しては何も出力し
ない．

%The ``\texttt{M}'' indicates that Mercurial has noticed that we
%modified \filename{hello.c}.  We didn't need to \emph{inform}
%Mercurial that we were going to modify the file before we started, or
%that we had modified the file after we were done; it was able to
%figure this out itself.

``\texttt{M}''の意味は，\filename{hello.c}に対して行われた変更を
Mercurialが把握したということである．ファイルの変更前にMercurialにこれか
ら変更するファイルを登録する必要はないし，変更後に行う必要もない．変更さ
れたファイルの発見は自動的に行われる．

%It's a somewhat helpful to know that we've modified
%\filename{hello.c}, but we might prefer to know exactly \emph{what}
%changes we've made to it.  To do this, we use the \hgcmd{diff}
%command.
%\interaction{tour.diff}

\filename{hello.c}を編集したことが分かるのは多少役に立つが，知りたいのは
むしろ\emph{何を}変更したのかである．\hgcmd{diff}コマンドを使えばこれを知
ることができる． \interaction{tour.diff}

%\begin{note}
%Understanding patches
%
%Remember to take a look at section~\ref{sec:mq:patch} if you don't know
%how to read output above.
%\end{note}

\begin{note}
パッチについて

上の出力の読み方が分からない場合は，\ref{sec:mq:patch}節を参照されたい．
\end{note}

%\section{Recording changes in a new changeset}
\section{新たなチェンジセットへ変更を記録する}

%We can modify files, build and test our changes, and use
%\hgcmd{status} and \hgcmd{diff} to review our changes, until we're
%satisfied with what we've done and arrive at a natural stopping point
%where we want to record our work in a new changeset.

ファイルを変更し，ビルドとテストを行い，\hgcmd{status}と\hgcmd{diff}を使っ
て変更のレビューを行い，気の済むところまでこれを繰返し，仕事の結果を新た
なチェンジセットに記録する．

%The \hgcmd{commit} command lets us create a new changeset; we'll
%usually refer to this as ``making a commit'' or ``committing''.

新たなチェンジセットを作成するには\hgcmd{commit}コマンドを使う．
この操作をよく``コミットする''とか``コミット''と呼ぶ．

%\subsection{Setting up a username}
\subsection{ユーザ名を設定する}

%When you try to run \hgcmd{commit} for the first time, it is not
%guaranteed to succeed.  Mercurial records your name and address with
%each change that you commit, so that you and others will later be able
%to tell who made each change.  Mercurial tries to automatically figure
%out a sensible username to commit the change with.  It will attempt
%each of the following methods, in order:

最初に\hgcmd{commit}を実行する場合，実行が成功するかどうかは保証されてい
ない．すべてのコミットでMercurialはユーザの名前とアドレスを記録し，後で誰
がその変更を行ったのか分かるようにしている． Mercurialは変更をコミットす
る際に自動的に妥当なユーザ名を付けようとする．
ユーザ名の推測は以下のような順序で行われる：
\begin{enumerate}
%\item If you specify a \hgopt{commit}{-u} option to the \hgcmd{commit}
%  command on the command line, followed by a username, this is always
%  given the highest precedence.
 \item \hgcmd{commit}コマンドに\hgopt{commit}{-u}オプションとユーザ名を付
       けた場合，これが最も優先される．
%\item If you have set the \envar{HGUSER} environment variable, this is
%  checked next.
 \item 環境変数\envar{HGUSER}を設定している場合は次にこれが参照される．
%\item If you create a file in your home directory called
%  \sfilename{.hgrc}, with a \rcitem{ui}{username} entry, that will be
%  used next.  To see what the contents of this file should look like,
%  refer to section~\ref{sec:tour-basic:username} below.
 \item ホームディレクトリに\sfilename{.hgrc}ファイルを作っている場
       合，\rcitem{ui}{username}エントリが次に参照される．このファイルの
       内容は\ref{sec:tour-basic:username}節で説明している．
%\item If you have set the \envar{EMAIL} environment variable, this
%  will be used next.
 \item 環境変数\envar{EMAIL}を設定しているなら次にこれが参照される．
%\item Mercurial will query your system to find out your local user
%  name and host name, and construct a username from these components.
%  Since this often results in a username that is not very useful, it
%  will print a warning if it has to do this.
 \item Mercurialはシステムにローカルユーザ名とホスト名を問い合わせ，これ
       らからコミットユーザ名を構成する．このユーザ名は役に立たないことが
       多いため，この方法を使った場合は警告メッセージが表示される．
\end{enumerate}
%If all of these mechanisms fail, Mercurial will fail, printing an
%error message.  In this case, it will not let you commit until you set
%up a username.
これらのメカニズムのすべてが失敗した場合，Mercurialはエラーメッセージを
表示して実行を断念する．この場合，ユーザ名を設定するまでコミットすること
はできない．

%You should think of the \envar{HGUSER} environment variable and the
%\hgopt{commit}{-u} option to the \hgcmd{commit} command as ways to
%\emph{override} Mercurial's default selection of username.  For normal
%use, the simplest and most robust way to set a username for yourself
%is by creating a \sfilename{.hgrc} file; see below for details.

環境変数\envar{HGUSER}と\hgcmd{commit}コマンドの\hgopt{commit}{-u}オプショ
ンは，Mercurialがデフォルトで設定するユーザ名を\emph{オーバライド}する方
法だと考えるとよい．通常の利用法でユーザ名を設定する最も簡単で最も頑強な
方法は\sfilename{.hgrc}ファイルを作成することである．このやり方について次
に述べる．

%\subsubsection{Creating a Mercurial configuration file}
\subsubsection{Mercurialの設定ファイルを作成する}
\label{sec:tour-basic:username}

%To set a user name, use your favorite editor to create a file called
%\sfilename{.hgrc} in your home directory.  Mercurial will use this
%file to look up your personalised configuration settings.  The initial
%contents of your \sfilename{.hgrc} should look like this.
%\begin{footnote}
%Figure out what the appropriate directory is on Windows.
%\end{footnote}
%\begin{codesample2}
%  # This is a Mercurial configuration file.
%  [ui]
%  username = Firstname Lastname <email.address@domain.net>
%\end{codesample2}
%The ``\texttt{[ui]}'' line begins a \emph{section} of the config file,
%so you can read the ``\texttt{username = ...}'' line as meaning ``set
%the value of the \texttt{username} item in the \texttt{ui} section''.
%A section continues until a new section begins, or the end of the
%file.  Mercurial ignores empty lines and treats any text from
%``\texttt{\#}'' to the end of a line as a comment.

ユーザ名を設定するには好みのエディタでホームディレクトリに
\sfilename{.hgrc}というファイルを作成する． Mercurialはこのファイルから個
人設定を取得し，使用する．\sfilename{.hgrc}ファイルの最初の内容は以下のよ
うな書式にする．
\footnote{Windowsでの適切なディレクトリを示すこと．}
\begin{codesample2}
  # This is a Mercurial configuration file.
  [ui]
  username = Firstname Lastname <email.address@domain.net>
\end{codesample2}
``\texttt{[ui]}''の行で設定ファイルの\emph{セクション}が始まる．
``\texttt{username = ...}''の行は``\texttt{ui}セクションの
\texttt{username}項目の値を設定する''と読むことができる．
セクションは新たな別のセクションが始まるか，ファイルが終了するまで続
く．Mercurialは空行を無視し，``\texttt{\#}''から行末までをコメントとして
扱う．

%\subsubsection{Choosing a user name}
\subsubsection{ユーザ名を選ぶ}

%You can use any text you like as the value of the \texttt{username}
%config item, since this information is for reading by other people,
%but will not be interpreted by Mercurial.  The convention that most
%people follow is to use their name and email address, as in the example
%above.

\texttt{username}の設定に使用する文字列は，他のユーザが読む情報であるに過
ぎず，Mercurialによって処理されるものではないため，どのような文字列でも構
わない．多くのユーザが従う習慣は，上の例のように名前とemailアドレスを使う
ものである．

\begin{note}
%  Mercurial's built-in web server obfuscates email addresses, to make
%  it more difficult for the email harvesting tools that spammers use.
%  This reduces the likelihood that you'll start receiving more junk
%  email if you publish a Mercurial repository on the web.
Mercurialの組み込みウェブサーバはemailアドレスをスパマーが使うemail収拾ツー
ルに拾われ難くするように改変し，Mercurialリポジトリをウェブで公開してもス
パムを受け取り難くしている．
\end{note}

%\subsection{Writing a commit message}
\subsection{コミットメッセージを書く}

%When we commit a change, Mercurial drops us into a text editor, to
%enter a message that will describe the modifications we've made in
%this changeset.  This is called the \emph{commit message}.  It will be
%a record for readers of what we did and why, and it will be printed by
%\hgcmd{log} after we've finished committing.
%\interaction{tour.commit}

変更をコミットする時，Mercurialはチェンジセットで行った変更について説明す
るメッセージを入力させるためにテキストエディタを起動する．
これは\emph{コミットメッセージ}と呼ばれる．
これは何をなぜ変更したのか読み手に伝えるもので，コミット完了後に
\hgcmd{log}で表示することができる．
\interaction{tour.commit}

%The editor that the \hgcmd{commit} command drops us into will contain
%an empty line or two, followed by a number of lines starting with
%``\texttt{HG:}''.
%%\begin{codesample2}
%This is where I type my commit comment.
%
%HG: Enter commit message.  Lines beginning with 'HG:' are removed.
%HG: --
%HG: user: Bryan O'Sullivan <bos@serpentine.com>
%HG: branch 'default'
%HG: changed hello.c</programlisting>
%\end{codesample2}
%Mercurial ignores the lines that start with ``\texttt{HG:}''; it uses
%them only to tell us which files it's recording changes to.  Modifying
%or deleting these lines has no effect.

\hgcmd{commit}コマンドが起動するエディタは，空行と``\texttt{HG:}''で始ま
る数行をすでに含んでいる．
\begin{codesample2}
This is where I type my commit comment.

HG: Enter commit message.  Lines beginning with 'HG:' are removed.
HG: --
HG: user: Bryan O'Sullivan <bos@serpentine.com>
HG: branch 'default'
HG: changed hello.c</programlisting>
\end{codesample2}
Mercurialは``\texttt{HG:}''で始まる行を無視する．これらの行はどのファイル
への変更なのかをユーザに伝えるだけの目的で存在する．これらの行を変更した
り消去したりしても何の影響も与えない．

%\subsection{Writing a good commit message}
\subsection{よいコミットメッセージの書き方}

%Since \hgcmd{log} only prints the first line of a commit message by
%default, it's best to write a commit message whose first line stands
%alone.  Here's a real example of a commit message that \emph{doesn't}
%follow this guideline, and hence has a summary that is not readable.
%\begin{codesample2}
%  changeset:   73:584af0e231be
%  user:        Censored Person <censored.person@example.org>
%  date:        Tue Sep 26 21:37:07 2006 -0700
%  summary:     include buildmeister/commondefs.   Add an exports and install
%\end{codesample2}

デフォルトでは\hgcmd{log}はコミットメッセージの最初の行しか表示しないため
コミットメッセージの最初の行は1行で完結するように書くとよい．
ガイドラインに\emph{従わない}ため読めないコミットメッセージの例を示す．
\begin{codesample2}
  changeset:   73:584af0e231be
  user:        Censored Person <censored.person@example.org>
  date:        Tue Sep 26 21:37:07 2006 -0700
  summary:     include buildmeister/commondefs.   Add an exports and install
\end{codesample2}

%As far as the remainder of the contents of the commit message are
%concerned, there are no hard-and-fast rules.  Mercurial itself doesn't
%interpret or care about the contents of the commit message, though
%your project may have policies that dictate a certain kind of
%formatting.

コミットメッセージの残りの部分には厳格なルールはない．プロジェクトでフォー
マットに関して要求するポリシーがあったとしても，Mercurialはコミットメッセー
ジを中断したり，特別の配慮をすることはない．

%My personal preference is for short, but informative, commit messages
%that tell me something that I can't figure out with a quick glance at
%the output of \hgcmdargs{log}{--patch}.

個人的には，簡潔かつ情報があり， \hgcmdargs{log}{--patch}を一見しただけで
はわからない部分について説明したコミットメッセージが好みである．

%\subsection{Aborting a commit}
\subsection{コミットを中止する}

%If you decide that you don't want to commit while in the middle of
%editing a commit message, simply exit from your editor without saving
%the file that it's editing.  This will cause nothing to happen to
%either the repository or the working directory.

コミットメッセージを編集中にコミットを取り止めたくなった時は，編集中のファ
イルをセーブせずにエディタを終了すればよい．こうするとリポジトリにもワー
キングディレクトリにも何も起きない．

%If we run the \hgcmd{commit} command without any arguments, it records
%all of the changes we've made, as reported by \hgcmd{status} and
%\hgcmd{diff}.

\hgcmd{commit}コマンドを引数なしで実行している場合，\hgcmd{status}コマン
ドや\hgcmd{diff}コマンドに現れるそれまでに行った変更は保存される．

%\subsection{Admiring our new handiwork}
\subsection{新たな作業を称賛する}

%Once we've finished the commit, we can use the \hgcmd{tip} command to
%display the changeset we just created.  This command produces output
%that is identical to \hgcmd{log}, but it only displays the newest
%revision in the repository.
%\interaction{tour.tip}
%We refer to the newest revision in the repository as the \emph{tip revision},
%or simply the \emph{tip}.

コミットの完了後，\hgcmd{tip}コマンドで今作成したチェンジセットを知ること
ができる．このコマンドの出力はリポジトリの最新リビジョンのみを表示すると
いう点を除けば\hgcmd{log}と全く同じである．
\interaction{tour.tip}
リポジトリの最新リビジョンは\emph{tipリビジョン}または単に\emph{tip}と呼
ばれる．

%By the way, the \hgcmpd{tip} command accepts many of the same options as
%\hgcmd{log}, so \hgopt{log}{-v} above indicates ``be verbose'',
%\hgopt{log}{-p} specifies ``print a patch''. The use of \hgopt{log}{-p}
%to print patches is another example of the consistent naming we
%mentioned earlier.

\hgcmd{tip}コマンドでは\hgcmd{log}コマンドのオプションの多くが使える．上
記の\hgopt{log}{-v}は``冗長''な表示を行うし，\hgopt{log}{-p}は``パッチの
表示''を行う．\hgopt{log}{-p}でパッチが表示されるのは，前述のオプション名
の一貫性を示すもう一つの例である．

%\section{Sharing changes}
\section{変更を共有する}

%We mentioned earlier that repositories in Mercurial are
%self-contained.  This means that the changeset we just created exists
%only in our \dirname{my-hello} repository.  Let's look at a few ways
%that we can propagate this change into other repositories.

Mercurialのリポジトリは自己充足的であるとすでに述べた．つまり，今作成した
チェンジセットは\dirname{my-hello}リポジトリにのみ存在している．この変更
を他のリポジトリに波及させるいくつかの方法を見てみよう．

%\subsection{Pulling changes from another repository}
\subsection{他のリポジトリから変更をpullする}
\label{sec:tour:pull}

%To get started, let's clone our original \dirname{hello} repository,
%which does not contain the change we just committed.  We'll call our
%temporary repository \dirname{hello-pull}.
%\interaction{tour.clone-pull}

始めるに当たって，今コミットした変更を含まないオリジナルの
\dirname{hello}リポジトリをクローンする．この一時的なリポジトリを
\dirname{hello-pull}と呼ぶことにする．
\interaction{tour.clone-pull}

%We'll use the \hgcmd{pull} command to bring changes from
%\dirname{my-hello} into \dirname{hello-pull}.  However, blindly
%pulling unknown changes into a repository is a somewhat scary
%prospect.  Mercurial provides the \hgcmd{incoming} command to tell us
%what changes the \hgcmd{pull} command \emph{would} pull into the
%repository, without actually pulling the changes in.
%\interaction{tour.incoming}

\hgcmd{pull}コマンドで変更を\dirname{my-hello}から\dirname{hello-pull}に
取り込む．未知の変更を盲目的にリポジトリにpullすることは少々恐ろし
い．Mercurialには\hgcmd{pull}コマンドでどのような変更がリポジトリに取り込
まれるのかを実際にはpullすることなく表示する\hgcmd{incoming}コマンドがあ
る．
\interaction{tour.incoming}

%Suppose you're pulling changes from a repository on the network
%somewhere. While you are looking at the \hgcmd{incoming} output, and
%before you pull those changes, someone might have committed something in
%the remote repository. This means that it's possible to pull more
%changes than you saw when using \hgcmd{incoming}.

おそらく読者はネットワーク上のどこかからリポジトリをpullするに違いない．
変更をpullする前，\hgcmd{incoming}の出力を見ている間に誰かがリモートリポ
ジトリに何かコミットすることも有り得る．この場合，\hgcmd{incoming}で見た
ものよりも多くの変更がpullされることになる．

%Bringing changes into a repository is a simple matter of running the
%\hgcmd{pull} command, and telling it which repository to pull from.
%\interaction{tour.pull}
%As you can see from the before-and-after output of \hgcmd{tip}, we
%have successfully pulled changes into our repository.  There remains
%one step before we can see these changes in the working directory.

変更をリポジトリに取り込むのは，取り込み元のリポジトリを指定して
\hgcmd{pull}コマンドを実行するだけのシンプルな操作である．
\interaction{tour.pull}
pullの前後の\hgcmd{tip}出力でリポジトリへの変更の取り込みに成功したかどう
かがわかる．ワーキングディレクトリに変更を反映させるにはもう1ステップが必
要である．

%\subsection{Updating the working directory}
\subsection{ワーキングディレクトリを更新する}

%We have so far glossed over the relationship between a repository and
%its working directory.  The \hgcmd{pull} command that we ran in
%section~\ref{sec:tour:pull} brought changes into the repository, but
%if we check, there's no sign of those changes in the working
%directory.  This is because \hgcmd{pull} does not (by default) touch
%the working directory.  Instead, we use the \hgcmd{update} command to
%do this.
%\interaction{tour.update}

ここまではリポジトリとワーキングディレクトリの関係をあまり明確にせずに来
た． \ref{sec:tour:pull}節で\hgcmd{pull}コマンドを使って変更をリポジトリ
に取り込んだが，注意深く見ると，それらの変更はワーキングディレクトリに反
映されていなかった．これは，\hgcmd{pull}コマンドは（デフォルトでは）ワー
キングディレクトリに手を付けないためである．ワーキングディレクトリを操作
するためには\hgcmd{update}コマンドを使う．
\interaction{tour.update}

%It might seem a bit strange that \hgcmd{pull} doesn't update the
%working directory automatically.  There's actually a good reason for
%this: you can use \hgcmd{update} to update the working directory to
%the state it was in at \emph{any revision} in the history of the
%repository.  If you had the working directory updated to an old
%revision---to hunt down the origin of a bug, say---and ran a
%\hgcmd{pull} which automatically updated the working directory to a
%new revision, you might not be terribly happy.

\hgcmd{pull}がワーキングディレクトリを自動的に更新しないのはいささか奇妙
に見えるかもしれない．しかしこれにはちゃんとした理由がある．ワーキングディ
レクトリは\hgcmd{update}でリポジトリのいかなるバージョンにも更新できる．
バグの原因を探るためにワーキングディレクトリを古いリビジョンにしている時，
\hgcmd{pull}を実行したためにワーキングディレクトリが最新のリビジョンになっ
たとしたら，受ける被害は少なくない．

%However, since pull-then-update is such a common thing to do,
%Mercurial lets you combine the two by passing the \hgopt{pull}{-u}
%option to \hgcmd{pull}.
%\begin{codesample2}
%  hg pull -u
%\end{codesample2}
%If you look back at the output of \hgcmd{pull} in
%section~\ref{sec:tour:pull} when we ran it without \hgopt{pull}{-u},
%you can see that it printed a helpful reminder that we'd have to take
%an explicit step to update the working directory:
%\begin{codesample2}
%  (run 'hg update' to get a working copy)
%\end{codesample2}

しかしながら，「pull後に更新」という操作はとてもよく行われるため，
\hgcmd{pull}コマンドにはこれら2つの操作を一度に行うオプション，
\hgopt{pull}{-u}がある．
\begin{codesample2}
  hg pull -u
\end{codesample2}
\ref{sec:tour:pull}節で\hgopt{pull}{-u}オプションなしで実行されている
\hgcmd{pull}コマンドの出力を改めて見てみると，ワーキングディレクトリを
明示的に更新しなければならないことを示す
\begin{codesample2}
  (run 'hg update' to get a working copy)
\end{codesample2}
という注意書きがあるのに気づく．

%To find out what revision the working directory is at, use the
%\hgcmd{parents} command.
%\interaction{tour.parents}
%If you look back at figure~\ref{fig:tour-basic:history}, you'll see
%arrows connecting each changeset.  The node that the arrow leads
%\emph{from} in each case is a parent, and the node that the arrow
%leads \emph{to} is its child.  The working directory has a parent in
%just the same way; this is the changeset that the working directory
%currently contains.

ワーキングディレクトリの現在のリビジョンを調べるには\hgcmd{parents}コマ
ンドを使う．
\interaction{tour.parents}
図~\ref{fig:tour-basic:history}を見直すと，各々のチェンジセットを結ぶ矢印
がある．矢印の出ているところが親で，矢印が示しているところが子である．ワー
キングディレクトリは同様に1つの親を持ち，これがワーキングディレクトリが現
在更新されているチェンジセットである．

%To update the working directory to a particular revision, give a
%revision number or changeset~ID to the \hgcmd{update} command.
%\interaction{tour.older}
%If you omit an explicit revision, \hgcmd{update} will update to the
%tip revision, as shown by the second call to \hgcmd{update} in the
%example above.

特定のリビジョンにワーキングディレクトリを更新するために
は，\hgcmd{update}コマンドにリビジョン番号またはチェンジセットIDを渡す．
\interaction{tour.older}
明示的にリビジョンを渡さなかった場合，上の例で2回目の\hgcmd{update}の実行
のように\hgcmd{update}コマンドはワーキングディレクトリをtipリビジョンへ更
新する．

%\subsection{Pushing changes to another repository}
\subsection{他のリポジトリに変更をpushする}

%Mercurial lets us push changes to another repository, from the
%repository we're currently visiting.  As with the example of
%\hgcmd{pull} above, we'll create a temporary repository to push our
%changes into.
%\interaction{tour.clone-push}
%The \hgcmd{outgoing} command tells us what changes would be pushed
%into another repository.
%\interaction{tour.outgoing}
%And the \hgcmd{push} command does the actual push.
%\interaction{tour.push}

Mercurialでは現在使用しているリポジトリから他のリポジトリに変更をpushする
ことができる．前述の\hgcmd{pull}コマンドのように，一時的なリポジトリを作っ
てそこに変更をpushしてみよう．
\interaction{tour.clone-push}
他のリポジトリにpushされる変更は\hgcmd{outgoing}コマンドで知ることができ
る．
\interaction{tour.outgoing}
\hgcmd{push}コマンドで実際にpushを行う．
\interaction{tour.push}

%As with \hgcmd{pull}, the \hgcmd{push} command does not update the
%working directory in the repository that it's pushing changes into.
%Unlike \hgcmd{pull}, \hgcmd{push} does not provide a \texttt{-u} option
%that updates the other repository's working directory.  This asymmetry
%is deliberate: the repository we're pushing to might be on a remote
%server and shared between several people. If we were to update its
%working directory while someone was working in it, their work would be
%disrupted.

\hgcmd{pull}コマンドと同様に，\hgcmd{push}コマンドはpush先のリポジトリの
ワーキングディレクトリの更新を行わない．\hgcmd{pull}コマンドと違って
\hgcmd{push}コマンドは，ワーキングディレクトリの更新を行う\texttt{-u}オプ
ションを持たない．この非対称性は意図的なもので，push先のリポジトリはリモー
トサーバ上にあるかもしれず，複数のユーザから共有されている可能性がある．
もし誰かが作業中のワーキングディレクトリを更新したら，その作業内容は台無
しになってしまう．

%What happens if we try to pull or push changes and the receiving
%repository already has those changes?  Nothing too exciting.
%\interaction{tour.push.nothing}

リポジトリがある変更をすでに持っているとき，同じ変更をpullまたはpushしよ
うとすると何が起きるだろうか？特に驚くようなことは起きない．
\interaction{tour.push.nothing}

%\subsection{Sharing changes over a network}
\subsection{変更をネットワークを通じて共有する}

%The commands we have covered in the previous few sections are not
%limited to working with local repositories.  Each works in exactly the
%same fashion over a network connection; simply pass in a URL instead
%of a local path.
%\interaction{tour.outgoing.net}
%In this example, we can see what changes we could push to the remote
%repository, but the repository is understandably not set up to let
%anonymous users push to it.
%\interaction{tour.push.net}

これより前のいくつかの節で扱ったコマンドは，ローカルリポジトリだけに限定
されない．どのコマンドもネットワーク経由でも全く同じに動作する．違いはロー
カルパスの代わりにURLを渡すだけである．
\interaction{tour.outgoing.net}
この例では，リポートリポジトリにpushしようとするが，当然のことながら匿名
のユーザにpushを許可しないように設定されているため，pushできない．
\interaction{tour.push.net}

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