%\chapter{Mercurial in daily use}
\chapter{Mercurialでの日常作業}
\label{chap:daily}

%\section{Telling Mercurial which files to track}
\section{追跡すべきファイルのMercurialへの登録}

%Mercurial does not work with files in your repository unless you tell
%it to manage them.  The \hgcmd{status} command will tell you which
%files Mercurial doesn't know about; it uses a ``\texttt{?}'' to
%display such files.

Mercurialは，ユーザによるファイル管理の指示がない限り，リポジトリ内のファ
イルであっても管理を行わない．Mercurialが管理しないファイルは
\hgcmd{status}コマンドを実行すると``\texttt{?}''と表示される．

%To tell Mercurial to track a file, use the \hgcmd{add} command.  Once
%you have added a file, the entry in the output of \hgcmd{status} for
%that file changes from ``\texttt{?}'' to ``\texttt{A}''.
%\interaction{daily.files.add}

Mercurialにファイルの追跡をさせるには，\hgcmd{add}コマンドを用いる．一度
ファイルを追加すると，\hgcmd{status}コマンドの出力は``\texttt{?}''から
``\texttt{A}''に変わる．
\interaction{daily.files.add}

%After you run a \hgcmd{commit}, the files that you added before the
%commit will no longer be listed in the output of \hgcmd{status}.  The
%reason for this is that by default, \hgcmd{status} only tells you about
%``interesting'' files---those that you have (for example) modified,
%removed, or renamed. If you have a repository that contains thousands of
%files, you will rarely want to know about files that Mercurial is
%tracking, but that have not changed.  (You can still get this
%information; we'll return to this later.)

\hgcmd{commit}コマンドを実行すると，commitの前に追加したファイルは
\hgcmd{status}の出力に現れなくなる．これは，\hgcmd{status}がデフォルトで
は，変更，削除，リネームなどを行った``注目すべき''ファイルのみを表示する
ためである．数千のファイルからなるリポジトリの場合，Mercurialが追跡してい
るものの，変更の加えられていないファイルについて何かを知りたいということ
は稀である．（もちろん知りたい場合は情報を得ることもできる．これについて
は後述する．）

%Once you add a file, Mercurial doesn't do anything with it
%immediately.  Instead, it will take a snapshot of the file's state the
%next time you perform a commit.  It will then continue to track the
%changes you make to the file every time you commit, until you remove
%the file.

追加したファイルに対してMercurialが直ちに行うことは何もないが，その代わり
に次回のコミット時にファイル状態のスナップショットを取る．そしてファイル
を削除するまでコミット毎にファイルの変化を追跡する．

%\subsection{Explicit versus implicit file naming}
\subsection{明示的なファイル命名対暗黙のファイル命名}

%A useful behaviour that Mercurial has is that if you pass the name of
%a directory to a command, every Mercurial command will treat this as
%``I want to operate on every file in this directory and its
%subdirectories''.
%\interaction{daily.files.add-dir}
%Notice in this example that Mercurial printed the names of the files
%it added, whereas it didn't do so when we added the file named
%\filename{myfile.txt} in the earlier example.

Mercurialの全てのコマンドは，引数としてディレクトリ名を渡すと，ディレクト
リの内の全てのファイルとサブディレクトリに対する操作であると解釈するため
便利である．
\interaction{daily.files.add-dir}
この例ではMercurialは追加したファイル名を表示しているが，前の例で
\filename{myfile.txt}という名前のファイルを追加した際には表示していなかっ
た点に注意されたい．

%What's going on is that in the former case, we explicitly named the file
%to add on the command line. The assumption that Mercurial makes in such
%cases is that we know what we are doing, and it doesn't print any
%output.

前の例では，コマンドラインで追加するファイルを明示的に指定したた
め，Mercurialはユーザが何をしようとしているのか分かっていると推定し，何も
表示しなかった．

%However, when we \emph{imply} the names of files by giving the name of
%a directory, Mercurial takes the extra step of printing the name of
%each file that it does something with.  This makes it more clear what
%is happening, and reduces the likelihood of a silent and nasty
%surprise.  This behaviour is common to most Mercurial commands.

しかしディレクトリ名を与えることでファイル名を暗黙的に与えた場合、
Mercurialは関連するファイルの名前を1つずつ表示する追加のステップを踏む．
これによって何が起こっているのか理解しやすくすると共に，沈黙裏に厄介な問
題が起こる可能性を減らしている．この挙動はMercurialの大半のコマンドに共
通している．

%\subsection{Aside: Mercurial tracks files, not directories}
\subsection{こぼれ話: Mercurialはディレクトリではなくファイルを追跡する}

%Mercurial does not track directory information.  Instead, it tracks
%the path to a file.  Before creating a file, it first creates any
%missing directory components of the path.  After it deletes a file, it
%then deletes any empty directories that were in the deleted file's
%path.  This sounds like a trivial distinction, but it has one minor
%practical consequence: it is not possible to represent a completely
%empty directory in Mercurial.

Mercurialはディレクトリ情報を追跡しない．その代わり，ファイルへのパスを追
跡している．ファイルを作成する際には，まずパスのディレクトリ部分を補完す
る．ファイルを消去した後は，ファイルの含まれていた空のディレクトリを全て
消去する．これは当然の挙動のように見えるが，実際上は小さな問題を引き起こ
す．すなわち，Mercurialは完全に空のディレクトリを表現することができないの
である．

%Empty directories are rarely useful, and there are unintrusive
%workarounds that you can use to achieve an appropriate effect.  The
%developers of Mercurial thus felt that the complexity that would be
%required to manage empty directories was not worth the limited benefit
%this feature would bring.

空のディレクトリが有用であることは滅多にないが，適当なワークアラウンドと
して，リポジトリの動きを妨げない方法が存在する．
Mercurialの開発者たちは，空のディレクトリを表現するために加わる複雑さは，そ
の機能に見合わないと考えた．

%If you need an empty directory in your repository, there are a few
%ways to achieve this. One is to create a directory, then \hgcmd{add} a
%``hidden'' file to that directory.  On Unix-like systems, any file
%name that begins with a period (``\texttt{.}'') is treated as hidden
%by most commands and GUI tools.  This approach is illustrated in
%figure~\ref{ex:daily:hidden}.

リポジトリに空のディレクトリが必要な場合，これを実現する方法がいくつかあ
る．1つ目は，まずディレクトリを作成し，隠しファイルをこのディレクトリ内に
\hgcmd{add}する．Unix系システムでは，ピリオド(``\texttt{.}'')で始まるファ
イルは大半のコマンドとGUIツールで隠しファイルとして取り扱われる．
詳細については図~\ref{ex:daily:hidden}を参照されたい．

\begin{figure}[ht]
  \interaction{daily.files.hidden}
%  \caption{Simulating an empty directory using a hidden file}
  \caption{隠しファイルを使って空のディレクトリをシミュレートする}
  \label{ex:daily:hidden}
\end{figure}

%Another way to tackle a need for an empty directory is to simply
%create one in your automated build scripts before they will need it.

空のディレクトリを扱う別の方法には，自動ビルドスクリプトの中で，必要になる
前に作成することがある．

%\section{How to stop tracking a file}
\section{ファイル追跡の停止}

%Once you decide that a file no longer belongs in your repository, use
%the \hgcmd{remove} command. This deletes the file, and tells Mercurial
%to stop tracking it.  A removed file is represented in the output of
%\hgcmd{status} with a ``\texttt{R}''.
%\interaction{daily.files.remove}

ファイルがリポジトリに必要なくなった時は\hgcmd{remove}コマンドを実行す
る．このコマンドはファイルを削除した上でMercurialにファイル追跡の停止を指
示する．削除されたファイルは\hgcmd{status}コマンドの出力で``\texttt{R}''
と表示される．
\interaction{daily.files.remove}

%After you \hgcmd{remove} a file, Mercurial will no longer track
%changes to that file, even if you recreate a file with the same name
%in your working directory.  If you do recreate a file with the same
%name and want Mercurial to track the new file, simply \hgcmd{add} it.
%Mercurial will know that the newly added file is not related to the
%old file of the same name.

一度ファイルを\hgcmd{remove}した後では，Mercurialはワーキングディレクトリ
内にたとえ同じ名前でファイルが再生成されてもファイルへの変更を追跡しない．
ファイルを再生成し，Mercurialに追跡させたいのであれば，\hgcmd{add}を行う．
Mercurialは，新規に追加されたファイルを同名の古いファイルと関係なく扱う．

%\subsection{Removing a file does not affect its history}
\subsection{ファイル削除は履歴に影響を与えない}

%It is important to understand that removing a file has only two
%effects.
ファイルの削除がリポジトリに与える影響は2つのみである．
\begin{itemize}
%\item It removes the current version of the file from the working
%  directory.
 \item ワーキングディレクトリから原稿のバージョンのファイルを消去する．
%\item It stops Mercurial from tracking changes to the file, from the
%  time of the next commit.
 \item 削除するファイルへの変更を次回のコミットからMercurialが追跡しない
       ようにする．
\end{itemize}
%Removing a file \emph{does not} in any way alter the \emph{history} of
%the file.
ファイルをどのように削除してもファイルの\emph{履歴}は変更\emph{されない}．

%If you update the working directory to a changeset that was committed
%when it was still tracking a file that you later removed, the file will
%reappear in the working directory, with the contents it had when you
%committed that changeset.  If you then update the working directory to a
%later changeset, in which the file had been removed, Mercurial will once
%again remove the file from the working directory.

ワーキングディレクトリを，消去したファイルが管理されていた頃にコミットさ
れたチェンジセットに更新すると，ファイルはそのチェンジセットのコミット時
の内容でワーキングディレクトリに再び現れる．そこでワーキングディレクトリ
をファイルの消去された後のチェンジセットに更新すると，Mercurialは再びファ
イルをワーキングディレクトリから消去する．

%\subsection{Missing files}
\subsection{欠落したファイル}

%Mercurial considers a file that you have deleted, but not used
%\hgcmd{remove} to delete, to be \emph{missing}.  A missing file is
%represented with ``\texttt{!}'' in the output of \hgcmd{status}.
%Mercurial commands will not generally do anything with missing files.
%\interaction{daily.files.missing}

Mercurialは，\hgcmd{remove}を使わずに消去されたファイルを\emph{欠落}した
ファイルとして扱う．欠落ファイルは\hgcmd{status}コマンドの出力で
``\texttt{!}''と表示される．Mercurialのコマンドは，通常，欠落したファイ
ルには何も行わない．
\interaction{daily.files.missing}

%If your repository contains a file that \hgcmd{status} reports as
%missing, and you want the file to stay gone, you can run
%\hgcmdargs{remove}{\hgopt{remove}{--after}} at any time later on, to
%tell Mercurial that you really did mean to remove the file.
%\interaction{daily.files.remove-after}

リポジトリ内で\hgcmd{status}コマンドが欠落とリポートするファイルがある場
合，\hgcmdargs{remove}{\hgopt{remove}{--after}}を実行して，Mercurialに欠
落ファイルが消去されたものであることを指示することができる．
\interaction{daily.files.remove-after}

%On the other hand, if you deleted the missing file by accident, use
%\hgcmdargs{revert}{\emph{filename}} to recover the file.  It will
%reappear, in unmodified form.
%\interaction{daily.files.recover-missing}

一方で，誤ってファイルを消去した場合，\hgcmdargs{revert}{\emph{filename}}を
実行することでファイルを修復することができる．ファイルは何も変更されない状態
で修復される．
\interaction{daily.files.recover-missing}

%\subsection{Aside: why tell Mercurial explicitly to remove a file?}
\subsection{こぼれ話: なぜMercurialへファイルの削除を明示的に指示しなけ
  ればならないか}

%You might wonder why Mercurial requires you to explicitly tell it that
%you are deleting a file.  Early during the development of Mercurial,
%it let you delete a file however you pleased; Mercurial would notice
%the absence of the file automatically when you next ran a
%\hgcmd{commit}, and stop tracking the file.  In practice, this made it
%too easy to accidentally remove a file without noticing.

なぜMercurialにファイルの削除を明示的に指示しなければならないのだろうか？
Mercurialの開発の初期には，ファイルがないことを検知すると，次に
\hgcmd{commit}が実行される時に自動的にファイルの追跡をやめていた．実際に
使ってみるとこの動作ではファイルを知らずのうちに失うことが頻発したのであ
る．

%\subsection{Useful shorthand---adding and removing files in one step}
\subsection{役に立つ簡略法---ファイルの追加と削除を1ステップで行う}

%Mercurial offers a combination command, \hgcmd{addremove}, that adds
%untracked files and marks missing files as removed.
%\interaction{daily.files.addremove}
%The \hgcmd{commit} command also provides a \hgopt{commit}{-A} option
%that performs this same add-and-remove, immediately followed by a
%commit.
%\interaction{daily.files.commit-addremove}

Mercurialは\hgcmd{addremove}という組み合わせコマンドを持っている．このコ
マンドは追跡されていないファイル群を追加し，欠落しているファイルを消去さ
れたとマークする．
\interaction{daily.files.addremove}
\hgcmd{commit}コマンドには\hgopt{commit}{-A}オプションがあり，同じ追加と
削除の操作をコミット直後に行う．
\interaction{daily.files.commit-addremove}

%\section{Copying files}
\section{ファイルのコピー}

%Mercurial provides a \hgcmd{copy} command that lets you make a new
%copy of a file.  When you copy a file using this command, Mercurial
%makes a record of the fact that the new file is a copy of the original
%file.  It treats these copied files specially when you merge your work
%with someone else's.

Mercurialには，ファイルの新しいコピーを作る\hgcmd{copy}コマンドがある．
このコマンドを使ってファイルをコピーすると，Mercurialは新しいファイルが
オリジナルの複製であることを記録する．複製されたファイルは，別の人による
変更をマージする時に特別な取り扱いがなされる．

%\subsection{The results of copying during a merge}
\subsection{マージ中のコピーの結果}

%What happens during a merge is that changes ``follow'' a copy.  To
%best illustrate what this means, let's create an example.  We'll start
%with the usual tiny repository that contains a single file.
%\interaction{daily.copy.init}
%We need to do some work in parallel, so that we'll have something to
%merge.  So let's clone our repository.
%\interaction{daily.copy.clone}
%Back in our initial repository, let's use the \hgcmd{copy} command to
%make a copy of the first file we created.
%\interaction{daily.copy.copy}

マージ中には，コピーに``従う''ことが起きる．これの意味するところを示すた
めに，例を挙げることにする．いつものように，ファイル1つだけを含む小さなリ
ポジトリを作成する．
\interaction{daily.copy.init}
マージすべき内容を作るために並行していくつかの作業を行う必要があるので，
リポジトリのクローンを行う．
\interaction{daily.copy.clone}
最初のリポジトリに戻って，\hgcmd{copy}コマンドを使って，作成したファイル
のコピーを行う．
\interaction{daily.copy.copy}

%If we look at the output of the \hgcmd{status} command afterwards, the
%copied file looks just like a normal added file.
%\interaction{daily.copy.status}
%But if we pass the \hgopt{status}{-C} option to \hgcmd{status}, it
%prints another line of output: this is the file that our newly-added
%file was copied \emph{from}.
%\interaction{daily.copy.status-copy}

その後で\hgcmd{status}コマンドの出力を見るとコピーされたファイルは通常通
りに追加されたファイルとして見える．
\interaction{daily.copy.status}
しかし\hgcmd{status}コマンドに\hgopt{status}{-C}オプションを渡すと，新た
に追加されたファイルが\emph{どの}ファイルからコピーされたのかを示す行が
出力される．
\interaction{daily.copy.status-copy}

%Now, back in the repository we cloned, let's make a change in
%parallel.  We'll add a line of content to the original file that we
%created.
%\interaction{daily.copy.other}
%Now we have a modified \filename{file} in this repository.  When we
%pull the changes from the first repository, and merge the two heads,
%Mercurial will propagate the changes that we made locally to
%\filename{file} into its copy, \filename{new-file}.
%\interaction{daily.copy.merge}

ここでクローンしたリポジトリにも変更を加える．作成したファイルに一行を追
加する．
\interaction{daily.copy.other}
これでこのリポジトリにも変更された\filename{file}が存在することにな
る．ここで最初のリポジトリから変更をpullし，2つのheadをマージすると
Mercurialはローカルな\filename{file}に対する変更をそのコピー
\filename{new-file}に波及させる．
\interaction{daily.copy.merge}

%\subsection{Why should changes follow copies?}
\subsection{変更はなぜコピーに従わなければならないか}
\label{sec:daily:why-copy}

%This behaviour---of changes to a file propagating out to copies of the
%file---might seem esoteric, but in most cases it's highly desirable.

ファイルへの変更がそのコピーへ波及する動作は難解に思えるかもしないが，多
くの場合は非常に望ましい動作である．

%First of all, remember that this propagation \emph{only} happens when
%you merge.  So if you \hgcmd{copy} a file, and subsequently modify the
%original file during the normal course of your work, nothing will
%happen.

まず第一にこの波及はマージを行うときに\emph{のみ}発生する．従ってファイル
を\hgcmd{copy}する場合や，通常の作業でオリジナルファイルを変更する場合は
何も起きない．

%The second thing to know is that modifications will only propagate
%across a copy as long as the changeset that you're merging changes from
%\emph{hasn't yet seen} the copy.

知っておくべき点の2つ目は，変更は変更のマージ元のチェンジセットがコピーを
\emph{関知していない場合}にのみ波及するということである．

%The reason that Mercurial does this is as follows.  Let's say I make
%an important bug fix in a source file, and commit my changes.
%Meanwhile, you've decided to \hgcmd{copy} the file in your repository,
%without knowing about the bug or having seen the fix, and you have
%started hacking on your copy of the file.

Mercurialがこのように動作する理由を説明する．今，私が重要なバグ修正を1つ
のソースファイルについて行い，変更をコミットしたとする．その間，あなたは
自分のリポジトリの中で，そのバグあるいは修正を知らず，そのファイルの
\hgcmd{copy}を行い，ファイルの変更を始めたとする．

%If you pulled and merged my changes, and Mercurial \emph{didn't}
%propagate changes across copies, your new source file would now contain
%the bug, and unless you knew to propagate the bug fix by hand, the bug
%would \emph{remain} in your copy of the file.

あなたが私の行った変更をpullし，mergeした場合，Mercurialは変更をコピー間
で波及させない．あなたの新しいソースファイルは今バグを持っているかもしれ
ないが，バグ修正を手で波及させなければバグはファイルのコピーに\emph{残る}．

%By automatically propagating the change that fixed the bug from the
%original file to the copy, Mercurial prevents this class of problem.
%To my knowledge, Mercurial is the \emph{only} revision control system
%that propagates changes across copies like this.

バグを修正する変更を自動的にオリジナルファイルからコピーへ波及させること
によって，Mercurialはこの類の問題を避けている．私の知る限
り，Mercurialは，このようなコピー間で変更を波及させる唯一のリビジョンコン
トロールシステムである．

%Once your change history has a record that the copy and subsequent merge
%occurred, there's usually no further need to propagate changes from the
%original file to the copied file, and that's why Mercurial only
%propagates changes across copies at the first merge, and not afterwards.

コピーと後続のマージが起こったことが更新履歴に含まれる場合，変更をオリジ
ナルファイルからコピーされたファイルへさらに波及させる必要はない．これが
Mercurialが最初のマージの時にコピー間で変更を波及させ，その後では行わない
理由である．

%\subsection{How to make changes \emph{not} follow a copy}
\subsection{変更がコピーに従わないようにする方法}

%If, for some reason, you decide that this business of automatically
%propagating changes across copies is not for you, simply use your
%system's normal file copy command (on Unix-like systems, that's
%\command{cp}) to make a copy of a file, then \hgcmd{add} the new copy
%by hand.  Before you do so, though, please do reread
%section~\ref{sec:daily:why-copy}, and make an informed decision that
%this behavior is not appropriate to your specific case.

何らかの理由でこのように変更が自動的に波及するやり方が好ましくないと思わ
れる場合は，システム標準のファイルコピーコマンド（UNIX系システムでは
\command{cp}）を使ってファイルのコピーを行い，\hgcmd{add}で新しいコピーを
手動で追加することができる．これを実際に行う前
に，~\ref{sec:daily:why-copy}節を再読し，このやり方の詳細を踏まえた上で，
あなたのケースに適しているか判断してほしい．

%\subsection{Behavior of the \hgcmd{copy} command}
\subsection{\hgcmd{copy}コマンドの挙動}

%When you use the \hgcmd{copy} command, Mercurial makes a copy of each
%source file as it currently stands in the working directory.  This
%means that if you make some modifications to a file, then \hgcmd{copy}
%it without first having committed those changes, the new copy will
%also contain the modifications you have made up until that point.  (I
%find this behaviour a little counterintuitive, which is why I mention
%it here.)

\hgcmd{copy}コマンドを使う時，Mercurialはワーキングディレクトリ内のファイ
ルをその時点の状態でコピーする．すなわち，ファイルに何らかの変更を加え，
変更のコミットをせずに\hgcmd{copy}を行うと，新たなコピーもその時点までに
加えた変更を含んでいる． （筆者はこの挙動はやや直観に反すると考えているた
め，敢えてここで言及した．）

%The \hgcmd{copy} command acts similarly to the Unix \command{cp} command
%(you can use the \hgcmd{cp} alias if you prefer). We must supply two or
%more arguments, of which the last is treated as the \emph{destination},
%and all others are \emph{sources}.

\hgcmd{copy}コマンドはUnixの\command{cp}と同様に振舞う．（\hgcmd{cp}エイ
リアスを定義して使うことも可能だ．）引数は2つ以上が必要で，最後の引数は
\emph{コピー先}で，それ以外の引数は\emph{コピー元}として扱われる．

%If you pass \hgcmd{copy} a single file as the source, and the
%destination does not exist, it creates a new file with that name.

コピー元として単一のファイルを指定し，コピー先ファイルが存在しない場合，
コマンドはコピー先ファイルを新規に作成する．

%\interaction{daily.copy.simple}
%If the destination is a directory, Mercurial copies its sources into
%that directory.
%\interaction{daily.copy.dir-dest}
%Copying a directory is recursive, and preserves the directory
%structure of the source.
%\interaction{daily.copy.dir-src}
%If the source and destination are both directories, the source tree is
%recreated in the destination directory.
%\interaction{daily.copy.dir-src-dest}

\interaction{daily.copy.simple}
コピー先がディレクトリの場合，Mercurialはコピー元をコピー先ディレクトリ
の中にコピーする．
\interaction{daily.copy.dir-dest}
ディレクトリのコピーは再帰的で，コピー元のディレクトリ構造を保つ．
\interaction{daily.copy.dir-src}
コピー元とコピー先が共にディレクトリの場合，コピー元のツリー構造がコピー
先のディレクトリの中に再現される．
\interaction{daily.copy.dir-src-dest}

%As with the \hgcmd{remove} command, if you copy a file manually and
%then want Mercurial to know that you've copied the file, simply use
%the \hgopt{copy}{--after} option to \hgcmd{copy}.
%\interaction{daily.copy.after}

\hgcmd{remove}コマンドと同様に，ファイルを手動でコピーした後で，Mercurialに
操作を通知したい場合は，\hgcmd{copy}コマンドに\hgopt{copy}{--after}オプ
ションを付ければよい．
\interaction{daily.copy.after}

%\section{Renaming files}
\section{ファイルのリネーム}

%It's rather more common to need to rename a file than to make a copy
%of it.  The reason I discussed the \hgcmd{copy} command before talking
%about renaming files is that Mercurial treats a rename in essentially
%the same way as a copy.  Therefore, knowing what Mercurial does when
%you copy a file tells you what to expect when you rename a file.

ファイルをリネームすることはファイルのコピーよりもよく行われる．ファイル
のリネームよりも前に\hgcmd{copy}について述べた理由は， Mercurialが本質的
にリネームをコピーと同様に扱うからである．従って，ファイルをコピーする時
にMercurialが行うことを知ることは，リネームの際に起こることを知ることにな
る．

%When you use the \hgcmd{rename} command, Mercurial makes a copy of
%each source file, then deletes it and marks the file as removed.
%\interaction{daily.rename.rename}
%The \hgcmd{status} command shows the newly copied file as added, and
%the copied-from file as removed.
%\interaction{daily.rename.status}

\hgcmd{rename}コマンドを使う時，Mercurialは各々のソースファイルをコピー
し，元のファイルを削除して，消去済みとマークする．
\interaction{daily.rename.rename}
\hgcmd{status}コマンドは新たにコピーされたファイルを追加されたファイルと
して表示し，コピーされたファイルを消去されたファイルと表示する．
\interaction{daily.rename.status}

%As with the results of a \hgcmd{copy}, we must use the
%\hgopt{status}{-C} option to \hgcmd{status} to see that the added file
%is really being tracked by Mercurial as a copy of the original, now
%removed, file.
%\interaction{daily.rename.status-copy}

\hgcmd{copy}コマンドの場合と同様に， \hgcmd{status}コマンドに
\hgopt{status}{-C}オプションを用いて，追加されたファイルが消去されたオリ
ジナルファイルのコピーとしてMercurialに追跡されているのかを調べることがで
きる．
\interaction{daily.rename.status-copy}

%As with \hgcmd{remove} and \hgcmd{copy}, you can tell Mercurial about
%a rename after the fact using the \hgopt{rename}{--after} option.  In
%most other respects, the behaviour of the \hgcmd{rename} command, and
%the options it accepts, are similar to the \hgcmd{copy} command.

\hgcmd{remove}と\hgcmd{copy}のように，\hgopt{rename}{--after}オプションを
使うことで，事後にリネームをすることができる．多くの点で\hgcmd{rename}コ
マンドの挙動と，このコマンドが受け入れるオプションは\hgcmd{copy}コマンド
と類似している．

%If you're familiar with the Unix command line, you'll be glad to know
%that \hgcmd{rename} command can be invoked as \hgcmd{mv}.

Unixコマンドに慣れているなら，\hgcmd{rename}の代わりに\hgcmd{mv}が使える
ことを知っているとよいだろう．

%\subsection{Renaming files and merging changes}
\subsection{ファイルのリネームと変更のマージ}

%Since Mercurial's rename is implemented as copy-and-remove, the same
%propagation of changes happens when you merge after a rename as after
%a copy.

Mercurialのリネームはコピーと削除として実装されており，リネーム後にマー
ジを行うのと，コピー後にマージを行うのでは同じ変更の波及が起きる．

%If I modify a file, and you rename it to a new name, and then we merge
%our respective changes, my modifications to the file under its
%original name will be propagated into the file under its new name.
%(This is something you might expect to ``simply work,'' but not all
%revision control systems actually do this.)

私がファイルを変更し，あなたがそのファイルをを新しい名前にリネームした場
合，我々がお互いの変更をマージすると元のファイル名に対する私の変更は，新
しいファイル名のファイルに波及する． （これができるのは当たり前と思うかも
しれないが，実のところ，全てのリビジョンコントロールシステムができるわけ
ではない．）

%Whereas having changes follow a copy is a feature where you can
%perhaps nod and say ``yes, that might be useful,'' it should be clear
%that having them follow a rename is definitely important.  Without
%this facility, it would simply be too easy for changes to become
%orphaned when files are renamed.

変更がコピーに従う機能が有用であることは，おそらく容易に同意が得られると
ころであると思われる．とりわけリネームに追従する機能はきわめて重要である
ことは明白である．もしこの機能がなければ，ファイルのリネームによって変更
はたやすく行き場を失ってしまうだろう．

%\subsection{Divergent renames and merging}
\subsection{名前とマージの発散}

%The case of diverging names occurs when two developers start with a
%file---let's call it \filename{foo}---in their respective
%repositories.

2人の開発者のリポジトリ間で1つのファイル ---\filename{foo}と呼ぶことにす
る--- について名前の発散が起こった場合について考えてみよう．

\interaction{rename.divergent.clone}
%Anne renames the file to \filename{bar}.
アンはファイルを\filename{bar}と改名した．
\interaction{rename.divergent.rename.anne}
%Meanwhile, Bob renames it to \filename{quux}. (Remember that \hgcmd{mv}
%is an alias for \hgcmd{rename}.)
その間，ボブは同じファイルを\filename{quux}と改名した．（\hgcmd{mv}が
\hgcmd{rename}のエイリアスであることに注意）
\interaction{rename.divergent.rename.bob}
%I like to think of this as a conflict because each developer has
%expressed different intentions about what the file ought to be named.
各々の開発者はファイルが何と呼ばれるべきか異なった意見を持っており，これ
は名前のコンフリクトである．

%What do you think should happen when they merge their work?
%Mercurial's actual behaviour is that it always preserves \emph{both}
%names when it merges changesets that contain divergent renames.
%\interaction{rename.divergent.merge}

彼らがマージを行った際にどうなればよいだろうか？ Mercurialの実際の挙動
は，発散したリネームがあるチェンジセットをマージした場合は常に\emph{両方}の
名前を保存する．
\interaction{rename.divergent.merge}

%Notice that while Mercurial warns about the divergent renames, it leaves
%it up to you to do something about the divergence after the merge.

Mercurialは名前の発散について警告するが，マージ後も名前の発散の解決はユー
ザに任せる点に注意．

%\subsection{Convergent renames and merging}
\subsection{リネームとマージによる収束}

%Another kind of rename conflict occurs when two people choose to
%rename different \emph{source} files to the same \emph{destination}.
%In this case, Mercurial runs its normal merge machinery, and lets you
%guide it to a suitable resolution.

2人のユーザが異なる\emph{ソース}ファイル群を同一の\emph{目的}ファイルにリ
ネームするとコンフリクトが起きる．この場合，Mercurialは通常のマージ機構を
起動し，ユーザに適切な解決を促す．

%\subsection{Other name-related corner cases}
\subsection{名前に関連したいくつかの問題}

%Mercurial has a longstanding bug in which it fails to handle a merge
%where one side has a file with a given name, while another has a
%directory with the same name.  This is documented as~\bug{29} .
%\interaction{issue29.go}

Mercurialには，一方を名前を与えたファイル，もう一方を同名のディレクトリと
してマージを行うと失敗するバグが以前からある．これは~\bug{29}としてドキュ
メント化されている．
\interaction{issue29.go}

%\section{Recovering from mistakes}
\section{ミスからの回復}

%Mercurial has some useful commands that will help you to recover from
%some common mistakes.

Mercurialには一般的なミスからの回復を助けるいくつかの有用なコマンドがある．

%The \hgcmd{revert} command lets you undo changes that you have made to
%your working directory.  For example, if you \hgcmd{add} a file by
%accident, just run \hgcmd{revert} with the name of the file you added,
%and while the file won't be touched in any way, it won't be tracked
%for adding by Mercurial any longer, either.  You can also use
%\hgcmd{revert} to get rid of erroneous changes to a file.

\hgcmd{revert}コマンドはワーキングディレクトリ内で行った変更を取り消す．
たとえば，誤って\hgcmd{add}を行った場合，追加したファイル名と共に
\hgcmd{revert}を実行すればファイルは何も変更されず，Mercurialの管理から外
される．また\hgcmd{revert}はファイルへの間違った変更を消去するのも使える．

%It's good to remember that the \hgcmd{revert} command is useful for
%changes that you have not yet committed.  Once you've committed a
%change, if you decide it was a mistake, you can still do something
%about it, though your options may be more limited.

\hgcmd{revert}コマンドは未コミットの変更に対して有効であることを覚えてお
くと良い．変更をコミットしたあとで，これが間違いであったことに気づいた場
合は，とれる手段はやや限られる．

%For more information about the \hgcmd{revert} command, and details
%about how to deal with changes you have already committed, see
%chapter~\ref{chap:undo}.

\hgcmd{revert}コマンドについてのより詳細な情報と，すでにコミットした変更
への操作については~\ref{chap:undo}の章を参照されたい．

%\section{Dealing with tricky merges}
\section{複雑なマージの取り扱い}

%In a complicated or large project, it's not unusual for a merge of two
%changesets to result in some headaches.  Suppose there's a big source
%file that's been extensively edited by each side of a merge: this is
%almost inevitably going to result in conflicts, some of which can take a
%few tries to sort out.

複雑なプロジェクトや大規模なプロジェクトでは， 2つのチェンジセットをマー
ジする時に頭を悩ませることが少なくない．マージ元の双方で盛んに編集されて
いる大きなソースファイルがあるとすると，コンフリクトが生じることはほぼ不
可避であり，収拾するためには少々手数がかかる．

%Let's develop a simple case of this and see how to deal with it.  We'll
%start off with a repository containing one file, and clone it
%twice.

このような場合について，簡単な例で解決方法をを見てみよう．まず，ファイル
1つのみを含むリポジトリを作り，これを二度クローンする．

%\interaction{ch04-resolve.init}

%In one clone, we'll modify the file in one way.

クローンの一方でファイルを変更する．

%\interaction{ch04-resolve.left}

%In another, we'll modify the file differently.

もう一方のクローンでも別の変更を行う．

%\interaction{ch04-resolve.right}

%Next, we'll pull each set of changes into our original repo.

次に元のリポジトリに各々の変更をpullする．

%\interaction{ch04-resolve.pull}

%We expect our repository to now contain two heads.

元のリポジトリには今ヘッドが2つある．

%\interaction{ch04-resolve.heads}

%Normally, if we run \hgcmd{merge} at this point, it will drop us into a
%GUI that will let us manually resolve the conflicting edits to

%\filename{myfile.txt}.  However, to simplify things for presentation
%here, we'd like the merge to fail immediately instead.  Here's one way
%we can do so.

通常の場合，ここで\hgcmd{merge}を実行すると，ファイル
\filename{myfile.txt}のコンフリクトを手動で解決するためのGUIが起動する．
しかしここでは説明を単純にするために，直ちに失敗するマージをしてみよう．
その方法はこのようになる．

%\interaction{ch04-resolve.export}

%We've told Mercurial's merge machinery to run the command
%\command{false} (which, as we desire, fails immediately) if it detects a
%merge that it can't sort out automatically.

自動的に片付かないマージが見つかった場合は，Mercurialのマージメカニズムが
\command{false}コマンド（これは希望通り直ちに失敗する．）を実行するよう
にさせる．

%If we now fire up \hgcmd{merge}, it should grind to a halt and report a
%failure.

ここで\hgcmd{merge}を実行すると，実行は停止して，マージの失敗が報告され
る．

%\interaction{ch04-resolve.merge}

%Even if we don't notice that the merge failed, Mercurial will prevent us
%from accidentally committing the result of a failed merge.

ユーザがマージの失敗に気付かない場合でも，Mercurialは自動的に失敗したマー
ジの結果のコミットを妨げる．

%\interaction{ch04-resolve.cifail}

%When \hgcmd{commit} fails in this case, it suggests that we use the
%unfamiliar \hgcmd{resolve} command.  As usual, \hgcmd{help resolve} will
%print a helpful synopsis.

\hgcmd{commit}が失敗すると，あまり馴染みのないコマンドである
\hgcmd{resolve}を使うようにメッセージが表示される．このコマンドの使用法は
いつも通り\hgcmd{help resolve}を実行することで見ることができる．

%\subsection{File resolution states}
\subsection{ファイル解決状態}

%When a merge occurs, most files will usually remain unmodified.  For
%each file where Mercurial has to do something, it tracks the state of
%the file.

マージの際にほとんどのファイルはそのまま残される．Mercurialは操作を行うファ
イルの状態を管理している．

\begin{itemize}
% \item A \emph{resolved} file has been successfully merged, either
%       automatically by Mercurial or manually with human intervention.
 \item \emph{解決済み}ファイルはマージが成功したファイルで，Mercurialに
       よって自動的に行われたか，人がマージ作業を行ったかは問わない．
% \item An \emph{unresolved} file was not merged successfully, and needs
%       more attention.
 \item \emph{未解決}ファイルはマージが失敗し，なんらかの修正が必要な
       ファイルである．
\end{itemize}

%If Mercurial sees \emph{any} file in the unresolved state after a merge,
%it considers the merge to have failed.  Fortunately, we do not need to
%restart the entire merge from scratch.

Mercurialはマージ後に未解決状態のファイルを見つけると，マージが失敗
したと判断する．幸いなことにこの場合でもマージを始めからやり直す必要はな
い．

%The \hgopt{resolve}{--list} or \hgopt{resolve}{-l} option to
%\hgcmd{resolve} prints out the state of each merged file.

\hgcmd{resolve}コマンドで\hgopt{resolve}{--list}オプションや
\hgopt{resolve}{-l}オプションを使うと，マージされた各々のファイルの状態
が表示される．

%\interaction{ch04-resolve.list}

%In the output from \hgcmd{resolve}, a resolved file is marked with
%\texttt{R}, while an unresolved file is marked with \texttt{U}.  If any
%files are listed with \texttt{U}, we know that an attempt to commit the
%results of the merge will fail.

\hgcmd{resolve}の出力で，解決済みファイルは\texttt{R}，未解決のファイル
は\texttt{U}と表される．\texttt{U}となるファイルがある場合，マージ結果の
コミットは失敗する．

%\subsection{Resolving a file merge}
\subsection{ファイルマージの解決}

%We have several options to move a file from the unresolved into the
%resolved state.  By far the most common is to rerun \hgcmd{resolve}.  If
%we pass the names of individual files or directories, it will retry the
%merges of any unresolved files present in those locations. We can also
%pass the \hgopt{resolve}{--all} or \hgopt{resolve}{-a} option, which
%will retry the merges of \emph{all} unresolved files.

ファイルを未解決状態から解決済み状態へ持っていく方法はいくつかあ
る．最もよく用いられるのが再度\hgcmd{resolve}を実行する方法である．このコ
マンドは各々のファイルやディレクトリの名前を渡すと，未解決のファイル
に対してマージを再度試みる． \hgopt{resolve}{--all}または
\hgopt{resolve}{-a}オプションを渡して\emph{全ての}未解決ファイルに対
して再マージを行うこともできる．

%Mercurial also lets us modify the resolution state of a file directly.
%We can manually mark a file as resolved using the
%\hgopt{resolve}{--mark} option, or as unresolved using the
%\hgopt{resolve}{--unmark} option.  This allows us to clean up a
%particularly messy merge by hand, and to keep track of our progress with
%each file as we go.

Mercurialによってファイルの解決状態を直接変更することも可能だ．
\hgopt{resolve}{--mark}オプションを使うことで，ファイルを解決済みとマー
クしたり，逆に\hgopt{resolve}{--unmark}オプションで未解決とマークする
こともできる．これらによって混乱したマージを手動で整理して，作業を続ける
ことができる．

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