# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1244373951 -32400
# Node ID 11bc9d788428769bb19cce19a96af2dd63bad728
# Parent  7dd855842de4e0f7d672e2ab72b69e3b96ca32cf
finished tour-basic.tex

diff -r 7dd855842de4 -r 11bc9d788428 ja/tour-basic.tex
--- a/ja/tour-basic.tex	Sat Jun 06 17:12:36 2009 +0900
+++ b/ja/tour-basic.tex	Sun Jun 07 20:25:51 2009 +0900
@@ -348,7 +348,10 @@
 %\hgcmd{log} identifies a changeset using both a number and a
 %hexadecimal string.
 
-\emph{用語}
+``a~changeset''というチェンジセットの\emph{呼び名}は自由だが，
+``a~\emph{specific} changeset''を参照する\emph{識別子}は非常に重要である．
+\hgcmd{log}コマンドの出力に含まれる\texttt{changeset}フィールドは，あるチェ
+ンジセットを番号と16進文字列で表していたことを思い出して欲しい．
 
 %\begin{itemize}
 %\item The revision number is \emph{only valid in that repository},
@@ -371,21 +374,22 @@
 %Three changes $a,b,c$ can easily appear in one repository as $0,1,2$,
 %while in another as $1,0,2$.
 
-この区別は重要である．``revision~33''
-
+この区別は重要である．誰かに``revision~33''と言った時，そのリビジョン33が
+自分のリポジトリのリポジトリのものとは\emph{違うものである}可能性は高い．
+その理由は，リビジョン番号はリポジトリに変更が現れた順序によって決ま
+り，Mercurialでは別のリポジトリで同じ変更が同じ順序で起こる保証はないため
+である． 3つの変更$a,b,c$は，あるリポジトリで$0,1,2$の順で起こり，別のリ
+ポジトリでは$1,0,2$の順序で起こり得る．
 
 %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はリビジョン番号を単に便利のための略記方として用いる．誰かとチェ
+Mercurialはリビジョン番号を単に便利のための略記法として用いる．誰かとチェ
 ンジセットについて議論したり，（バグ報告などのために）チェンジセットを記
 録したい場合は16進の識別子を利用すべきである．
 
-
-
-
 %\subsection{Viewing specific revisions}
 \subsection{特定のリビジョンを見る}
 
@@ -394,6 +398,12 @@
 %revision number or a long-form 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}）オプションを用いる．リビジョ
+ン番号も長形式のチェンジセット識別子も利用可能であり，指定できるリビジョ
+ンの数に制限はない．
+\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$,
@@ -403,6 +413,13 @@
 %\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{より詳細な情報}
 
@@ -414,12 +431,25 @@
 %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}
+
 %\section{All about command options}
 \section{コマンドオプションのすべて}
 
@@ -427,31 +457,54 @@
 %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.
-%\begin{itemize}
+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.
-%\end{itemize}
+ \item オプションの命名と使用法はコマンド間で一貫している．例を挙げると，
+       チェンジセットIDまたはリビジョン番号を指定させるコマンドの全てで
+       \hgopt{log}{-r}と\hgopt{log}{--rev}の両方を受け付ける．
+\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}）オプションを付けるとより簡潔な出力となる．
 
 %\section{Making and reviewing changes}
 \section{変更の仕方，変更のレビュー}
@@ -459,6 +512,9 @@
 %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
@@ -474,6 +530,19 @@
 %local clones are so cheap, there's almost no overhead to cloning and
 %destroying repositories whenever you want.
 
+まず最初にこの実験を本来のリポジトリから隔離するために\hgcmd{clone}を行
+う．すでにローカルなリポジトリを持っているので，これをクローンするだけで
+よく，リモートのリポジトリをコピーする必要はない．ローカルなクローンはネッ
+トワーク越しに行うクローンよりもずっと速く，多くの場合使用するディスク容
+量も少ない．
+\interaction{tour.reclone}
+また，何か作業をしたい時にサンドボックスとするために一時的なクローンを作
+成し，リモートリポジトリのコピーを``清潔''に保つことはしばしば役に立つ．
+これにより複数の作業を並行して行うことができ，かつ，作業が完了し，再び統
+合するまで他の作業から隔離されたままにしておくことができる．リポジトリの
+ローカルクローンはとても手軽で，クローンと廃棄にほとんどオーバヘッドがな
+い．
+
 %In our \dirname{my-hello} repository, we have a file
 %\filename{hello.c} that contains the classic ``hello, world'' program.
 %Let's use the ancient and venerable \command{sed} command to edit this
@@ -484,6 +553,13 @@
 %do the same thing.)
 %\interaction{tour.sed}
 
+\dirname{my-hello}リポジトリ内にはクラシックな``hello, world''プログラム
+である\filename{hello.c}がある．古くさく森厳な\command{sed}を用いて2行目
+の出力を行うように変更する．（\command{sed}を使うのはスクリプトによる例を
+作るのが簡単だからに過ぎない．読者まで\command{sed}を使う必要はなく，好き
+なテキストエディタで編集してよい．）
+\interaction{tour.sed}
+
 %Mercurial's \hgcmd{status} command will tell us what Mercurial knows
 %about the files in the repository.
 %\interaction{tour.status}
@@ -492,18 +568,35 @@
 %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 little bit 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}
+
 %\section{Recording changes in a new changeset}
 \section{新たなチェンジセットへ変更を記録する}
 
@@ -512,9 +605,16 @@
 %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{ユーザ名を設定する}
 
@@ -524,26 +624,45 @@
 %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:
-%\begin{enumerate}
+
+最初に\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.
-%\end{enumerate}
+ \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
@@ -551,6 +670,12 @@
 %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}
@@ -571,6 +696,22 @@
 %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}ファイルの最初の内容は以下のよ
+うな書式にする．
+\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{ユーザ名を選ぶ}
 
@@ -580,12 +721,20 @@
 %follow is to use their name and email address, as in the example
 %above.
 
-%\begin{note}
+\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.
-%\end{note}
+Mercurialの組み込みウェブサーバはemailアドレスをスパマーが使うemail収拾ツー
+ルに拾われ難くするように改変し，Mercurialリポジトリをウェブで公開してもス
+パムを受け取り難くしている．
+\end{note}
 
 %\subsection{Writing a commit message}
 \subsection{コミットメッセージを書く}
@@ -597,6 +746,13 @@
 %\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, followed by a number of lines starting with
 %``\texttt{HG:}''.
@@ -608,6 +764,16 @@
 %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}
+  \emph{empty line}
+  HG: changed hello.c
+\end{codesample2}
+Mercurialは``\texttt{HG:}''で始まる行を無視する．これらの行はどのファイル
+への変更なのかをユーザに伝えるだけの目的で存在する．これらの行を変更した
+り消去したりしても何の影響も与えない．
+
 %\subsection{Writing a good commit message}
 \subsection{よいコミットメッセージの書き方}
 
@@ -622,16 +788,33 @@
 %  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{コミットを中止する}
 
@@ -640,10 +823,17 @@
 %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{新たな作業を称賛する}
 
@@ -655,6 +845,12 @@
 %We refer to the newest revision in the repository as the tip revision,
 %or simply the tip.
 
+コミットの完了後，\hgcmd{tip}コマンドで今作成したチェンジセットを知ること
+ができる．このコマンドの出力はリポジトリの最新リビジョンのみを表示すると
+いう点を除けば\hgcmd{log}と全く同じである．
+\interaction{tour.tip}
+リポジトリの最新リビジョンはtipリビジョンまたは単にtipと呼ばれる．
+
 %\section{Sharing changes}
 \section{変更を共有する}
 
@@ -663,6 +859,10 @@
 %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}
@@ -672,6 +872,11 @@
 %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
@@ -684,6 +889,16 @@
 %\hgcmd{pull} the changes, so that we could end up pulling changes that we
 %didn't expect.)
 
+\hgcmd{pull}コマンドで変更を\dirname{my-hello}から\dirname{hello-pull}に
+取り込む．未知の変更を盲目的にリポジトリにpullすることは少々恐ろし
+い．Mercurialには\hgcmd{pull}コマンドでどのような変更がリポジトリに取り込
+まれるのかを実際にはpullすることなく表示する\hgcmd{incoming}コマンドがあ
+る．
+\interaction{tour.incoming}
+（もちろん\hgcmd{incoming}を実行してから実際に\hgcmd{pull}するまでの間に
+誰かが新たなチェンジセットを追加し，その結果，予期しないチェンジセットを
+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}
@@ -691,6 +906,13 @@
 %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{ワーキングディレクトリを更新する}
 
@@ -703,6 +925,14 @@
 %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
@@ -712,6 +942,13 @@
 %\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}.
@@ -726,6 +963,20 @@
 %  (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}
@@ -736,6 +987,14 @@
 %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}
@@ -743,6 +1002,13 @@
 %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する}
 
@@ -761,10 +1027,28 @@
 %(Unlike \hgcmd{pull}, \hgcmd{push} does not provide a \texttt{-u}
 %option that updates the other repository's working directory.)
 
+Mercurialでは現在使用しているリポジトリから他のリポジトリに変更をpushする
+ことができる．前述の\hgcmd{pull}コマンドのように，一時的なリポジトリを作っ
+てそこに変更をpushしてみよう．
+\interaction{tour.clone-push}
+他のリポジトリにpushされる変更は\hgcmd{outgoing}コマンドで知ることができ
+る．
+\interaction{tour.outgoing}
+\hgcmd{push}コマンドで実際にpushを行う．
+\interaction{tour.push}
+\hgcmd{pull}コマンドと同様に，\hgcmd{push}コマンドはpush先のリポジトリの
+ワーキングディレクトリの更新を行わない．（\hgcmd{pull}コマンドと違って
+\hgcmd{push}コマンドは，ワーキングディレクトリの更新を行う\texttt{-u}オプ
+ションを持たない．）
+
 %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{変更をネットワークを通じて共有する}
 
@@ -778,8 +1062,13 @@
 %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