%\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 \hgcmd{status} only tells you about
%``interesting'' files---those that you have modified or told Mercurial
%to do something with---by default.  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に何かをさせたといった``注目すべき''ファイルの
みを表示するためである．数千のファイルからなるリポジトリの場合，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{a} in the earlier example.

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

%What's going on is that in the former case, we explicitly named the
%file to add on the command line, so the assumption that Mercurial
%makes in such cases is that you know what you were 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 in which a file
%that you have removed was still tracked, it 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 thatmodifications will only propagate
%across a copy as long as the repository that you're pulling changes
%from \emph{doesn't know} about the copy.

知っておくべき点の2つ目は，変更をpullするリポジトリが，コピーについて
\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 source file would now contain
%the bug, and unless you remembered 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 until this point, and no
%further.

コピーと後続のマージが起こったことが更新履歴に含まれる場合，変更をオリジ
ナルファイルからコピーされたファイルへさらに波及させる必要はない．これが
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 behaviour is not appropriate to your specific case.

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

%\subsection{Behaviour 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).  The last
%argument is the \emph{destination}, and all prior arguments are
%\emph{sources}.  If you pass it 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}

\hgcmd{copy}コマンドはUnixの\command{cp}と同様に振舞う．（\hgcmd{cp}エイ
リアスを定義して使うことも可能だ．）引数の最後は\emph{コピー先}で，それ以
前の引数は\emph{コピー元}である．コピー元として単一のファイルを指定し，コ
ピー先ファイルが存在しない場合，コマンドはコピー先ファイルを新規に作成す
る．
\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{rename} 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{rename}コマンドと同様に，ファイルを手動でコピーした後で，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}コマンド
と類似している．

%\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}.
その間，ボブは同じファイルを\filename{quux}と改名した．
\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 Mercurial does warn about the divergent renames, but 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 useful 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}の章を参照されたい．

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