foozy@708: \chapter{Mercurial in daily use}
foozy@708: \label{chap:daily}
foozy@708: 
foozy@708: \section{Telling Mercurial which files to track}
foozy@708: 
foozy@708: ファイルの管理を指示しない限り、
foozy@708: リポジトリ中のファイルに対して Mercurial は何も行いません。
foozy@708: \hgcmd{status} コマンドは、
foozy@708: Mercurial の管理下に無いファイルを
foozy@708: ``\texttt{?}'' を表示することで知らせてくれます
foozy@708: 
foozy@708: Mercurial による構成管理を指示するには、
foozy@708: \hgcmd{add} コマンドを使用します。
foozy@708: ファイルの構成管理を指示したファイルの
foozy@708: \hgcmd{status} による表示は、
foozy@708: ``\texttt{?}'' から ``\texttt{A}'' へと変化します。
foozy@708: 
foozy@708: \interaction{daily.files.add}
foozy@708: 
foozy@708: \hgcmd{commit} を実行した直後は、
foozy@708: コミット前に追加したファイルが
foozy@708: \hgcmd{status} により表示されることはありません。
foozy@708: これは、
foozy@708: ``興味深い''ファイル---
foozy@708: 変更したり、Mercurial に何らかの操作を要求したファイル
foozy@708: ---について表示するのが
foozy@708: \hgcmd{status} の役割だからです。
foozy@708: 数千のファイルから成るリポジトリがある場合、
foozy@708: 構成管理されてはいても特に変更されていないファイルの一覧
foozy@708: （後述するように、そのようなファイル一覧の情報を得ることもできます）
foozy@708: を欲しいと思うことは稀です。
foozy@708: 
foozy@708: 一旦ファイルを追加したとしても、
foozy@708: そのファイルに対して Mercurial はすぐには何も行いません。
foozy@708: その代わり、
foozy@708: 次にコミットを行った際にファイル状態のスナップショットを作成します。
foozy@708: Mercurial はそれ以降、
foozy@708: 構成管理下から除外するまで、
foozy@708: コミットの際には常に当該ファイルの変更状況を確認します。
foozy@708: 
foozy@708: \subsection{Explicit versus implicit file naming}
foozy@708: 
foozy@708: Mercurial の有用な振る舞いとして、
foozy@708: Mercurial のコマンドにディレクトリ名を指定した場合、
foozy@708: その指定を
foozy@708: ``当該ディレクトリ配下の全てのファイル\footnote{訳注:
foozy@708: 当該ディレクトリ直下のファイルならびに、
foozy@708: サブディレクトリ以下のファイル全て}に対する操作の実施''
foozy@708: が要求されたものとみなします。
foozy@708: 
foozy@708: \interaction{daily.files.add-dir}
foozy@708: 
foozy@708: 先の例で \filename{a} 
foozy@708: ファイルを構成管理対象に追加した際には、
foozy@708: Mercurial は追加されたファイルのファイル名を表示していませんが、
foozy@708: この例では
foozy@708: 構成管理対象に追加されたファイルを表示している点に注意してください。
foozy@708: 
foozy@708: 先の例では、
foozy@708: 追加するファイル名をコマンドラインで明示的に指定しましたので、
foozy@708: そのような場合は利用者自身が自分の振る舞いを理解しているものとみなし、
foozy@708: Mercurial は何も表示しません。
foozy@708: 
foozy@708: しかし、
foozy@708: ディレクトリ名を指定することでファイル名を\emph{暗示}した場合、
foozy@708: Mercurial は特別に操作対象となった個々のファイル名を表示します。
foozy@708: こうすることで何が実施されたのかが明確になるため、
foozy@708: ひっそりとやっかいな問題が発生する可能性を低減します。
foozy@708: この振る舞いは殆どの
foozy@708: Mercurial コマンドに共通しています。
foozy@708: 
foozy@708: \subsection{Aside: Mercurial tracks files, not directories}
foozy@708: 
foozy@708: ディレクトリは Mercurial による構成管理の対象にはなりません。
foozy@708: その代わり、
foozy@708: Mercurial はファイルのパスを構成管理します。
foozy@708: ファイルの生成の際には、
foozy@708: それに先立ってパスに含まれる存在しないディレクトリを全て作成します。
foozy@708: ファイルの削除の際には、
foozy@708: 削除されたファイルへのパスに含まれる空ディレクトリを全て削除します。
foozy@708: たわいも無いことに聞こえるかもしれませんが、
foozy@708: Mercurial が完全に空っぽのディレクトリを取り扱えない、
foozy@708: という小さいながらも実用上重大な性質を示しています。
foozy@708: 
foozy@708: 空のディレクトリが有用なことは滅多に無いですし、
foozy@708: 妥当な効果を得るための控えめな回避方法があります。
foozy@708: Empty directories are rarely useful, and there are unintrusive
foozy@708: workarounds that you can use to achieve an appropriate effect.  
foozy@708: それ故に、
foozy@708: 空のディレクトリを扱うことによる限定的な有益性が、
foozy@708: それに必要とされる複雑さに見合うものではない、
foozy@708: と Mercurial の開発陣は判断しました。
foozy@708: 
foozy@708: 空のディレクトリをリポジトリで管理したい場合、
foozy@708: 複数の実現方法があります。
foozy@708: １つは当該ディレクトリ直下の``隠し''ファイルを 
foozy@708: \hgcmd{add} することです。
foozy@708: UNIX ライクなシステムでは、
foozy@708: ピリオド（``\texttt{.}''）で始まる名前のファイルは、
foozy@708: 殆どのコマンドや GUI ツールから隠しファイルとして扱われます。
foozy@708: この手法を図~\ref{ex:daily:hidden}に示します。
foozy@708: 
foozy@708: \begin{figure}[ht]
foozy@708:   \interaction{daily.files.hidden}
foozy@708:   \caption{Simulating an empty directory using a hidden file}
foozy@708:   \label{ex:daily:hidden}
foozy@708: \end{figure}
foozy@708: 
foozy@708: 空ディレクトリを必要とする場合のもう一つの解決方法は、
foozy@708: 自動化されたビルドスクリプトで必要になる都度作成する、
foozy@708: というものです。
foozy@708: 
foozy@708: \section{How to stop tracking a file}
foozy@708: 
foozy@708: リポジトリにとって不要になった\footnote{訳注:
foozy@708: 構成管理の必要性がなくなった}ファイルがある場合は、
foozy@708: \hgcmd{remove} コマンドを使用ます。
foozy@708: このコマンドはファイルを削除しつつ、
foozy@708: Mercurial に構成管理対象からファイルを除外する旨を通知します。
foozy@708: 削除されたファイルは、
foozy@708: \hgcmd{status} の出力では
foozy@708: ``\texttt{R}'' 付きで表示されます。
foozy@708: 
foozy@708: \interaction{daily.files.remove}
foozy@708: 
foozy@708: \hgcmd{remove} によるファイルの削除を行うと、
foozy@708: 作業領域ディレクトリに同名のファイルを再度作成したとしても、
foozy@708: Mercurial はそのファイルを構成管理対象から除外します。
foozy@708: 同名ファイルを再生成し Mercurial による構成管理を行う場合には、
foozy@708: 単純にそのファイルを \hgcmd{add} してください。
foozy@708: Mercurial は新規に管理対象に加えられたファイルが、
foozy@708: 以前管理していた同名のファイルとは無関係であるとみなします。
foozy@708: 
foozy@708: \subsection{Removing a file does not affect its history}
foozy@708: 
foozy@708: 重要な事ですので、
foozy@708: \hgcmd{remove} コマンドによる操作が持つ影響は２つだけである、
foozy@708: と理解してください。
foozy@708: 
foozy@708: \begin{itemize}
foozy@708: \item 作業領域ディレクトリから、現時点のファイルを削除します
foozy@708: 
foozy@708: \item Mercurial に対して、次回のコミット以降、
foozy@708:   当該ファイルを構成管理対象から除外するように通知します
foozy@708: 
foozy@708: \end{itemize}
foozy@708: 
foozy@708: \hgcmd{remove} コマンドによる操作は、
foozy@708: ファイルの\emph{変更履歴}には一切変更を加え\emph{ません}。
foozy@708: 
foozy@708: 作業領域ディレクトリを
foozy@708: \hgcmd{remove} 
foozy@708: で削除したファイルがまだ構成管理されていた時点のチェンジセットで更新した場合、
foozy@708: そのチェンジセットがコミットされた時点の内容で、
foozy@708: 作業領域ディレクトリに当該ファイルが再生成されます。
foozy@708: その後で、
foozy@708: 当該ファイルが \hgcmd{remove} 
foozy@708: で削除された時点のチェンジセットで更新すると、
foozy@708: Mercurial は再び当該ファイルを作業領域から削除します。
foozy@708: 
foozy@708: \subsection{Missing files}
foozy@708: 
foozy@708: \hgcmd{remove} 
foozy@708: コマンドを使用せずに作業領域ディレクトリから削除したファイルを、
foozy@708: Mercurial は\emph{行方不明}とみなします。
foozy@708: 行方不明のファイルは、
foozy@708: \hgcmd{status} の出力では
foozy@708: ``\texttt{!}'' 付きで表示されます。
foozy@708: Mercurial のコマンド群全般は、
foozy@708: 行方不明のファイルに関しては何も行いません。
foozy@708: 
foozy@708: \interaction{daily.files.missing}
foozy@708: 
foozy@708: \hgcmd{status} 
foozy@708: が行方不明として表示するファイルがリポジトリ中にある場合\footnote{訳注:
foozy@708: つまり手動でファイルを削除した場合}、
foozy@708: ファイル削除後の任意の時点で
foozy@708: \hgcmdargs{remove}{\hgopt{remove}{--after}} を実行することで
foozy@708: 当該ファイルを構成管理対象から除外する意思があることを
foozy@708: Mercurial に通知することができます。
foozy@708: 
foozy@708: \interaction{daily.files.remove-after}
foozy@708: 
foozy@708: その一方で、
foozy@708: 行方不明とされているファイルが意図せずに削除してしまったものなら、
foozy@708: \hgcmd{revert} に当該ファイル名を指定することで、
foozy@708: 変更されていない状態にファイルを復旧することができます。
foozy@708: 
foozy@708: \interaction{daily.files.recover-missing}
foozy@708: 
foozy@708: \subsection{Aside: why tell Mercurial explicitly to remove a file?}
foozy@708: 
foozy@708: ファイル削除の意思表示を一々 Mercurial に示す必要性について、
foozy@708: 疑問に思われるかもしれません。
foozy@708: Mercurial の開発初期における削除方法は、
foozy@708: そのように思う人にとっては望ましいものかもしれません。
foozy@708: Mercurial は \hgcmd{commit} コマンド実行時にファイルの不在を自動的に検知し、
foozy@708: 当該ファイルを構成管理対象から除外していたのです。
foozy@708: 実際問題、この削除方法では、
foozy@708: 不慮の事態で通知も無くファイルが削除される事態が容易に起こり得ます。
foozy@708: 
foozy@708: \subsection{Useful shorthand---adding and removing files in one step}
foozy@708: 
foozy@708: Mercurial は、
foozy@708: 構成管理対象へのファイルの追加と除外を行う、
foozy@708: 組み合わせコマンドである \hgcmd{addremove} を提供しています。
foozy@708: 
foozy@708: \interaction{daily.files.addremove}
foozy@708: 
foozy@708: \hgcmd{commit} コマンドも、
foozy@708: コミット実施の直前に
foozy@708: \hgcmd{addremove} と同じ方針で構成管理対象への追加／除外を行う
foozy@708: \hgopt{commit}{-A} オプションを提供しています。
foozy@708: 
foozy@708: \interaction{daily.files.commit-addremove}
foozy@708: 
foozy@708: \section{Copying files}
foozy@708: 
foozy@708: Mercurial はファイルの複製を行う
foozy@708: \hgcmd{copy} コマンドを提供しています。
foozy@708: このコマンドでファイルを複製した場合、
foozy@708: Mercurial はそのファイルが元ファイルの複製であることを記録します。
foozy@708: チェンジセットのマージの際には、
foozy@708: Mercurial はこの複製ファイルを特別扱いします。
foozy@708: 
foozy@708: \subsection{The results of copying during a merge}
foozy@708: 
foozy@708: 複製ファイルのマージの際には、
foozy@708: 変更内容が複製ファイルまで``追従''してきます。
foozy@708: このことが持つ意味を上手く説明するために、
foozy@708: 簡単な例を作成しましょう。
foozy@708: これまでの例と同様に、
foozy@708: １つだけファイルを持つ簡易的なリポジトリを作成します。
foozy@708: 
foozy@708: \interaction{daily.copy.init}
foozy@708: 
foozy@708: マージを行うためには、
foozy@708: 別々の作業を平行して行う必要がありますので、
foozy@708: リポジトリを複製しましょう。
foozy@708: 
foozy@708: \interaction{daily.copy.clone}
foozy@708: 
foozy@708: 最初のリポジトリに戻り、
foozy@708: \hgcmd{copy} コマンドで最初に作成したファイルを複製します。
foozy@708: 
foozy@708: \interaction{daily.copy.copy}
foozy@708: 
foozy@708: 複製後の \hgcmd{status} コマンドの出力では、
foozy@708: 複製されたファイルは単に追加された普通のファイルと同じように見えます。
foozy@708: 
foozy@708: \interaction{daily.copy.status}
foozy@708: 
foozy@708: しかし
foozy@708: \hgopt{status}{-C} オプション付きで
foozy@708: \hgcmd{status} を実行することで、
foozy@708: 別な行が表示されます。
foozy@708: この行は、新たに追加されたファイルの複製\emph{元}であることを意味します。
foozy@708: 
foozy@708: \interaction{daily.copy.status-copy}
foozy@708: 
foozy@708: 複製したリポジトリに戻り、
foozy@708: 平行して変更作業を行います。
foozy@708: 複製元になったファイルに対して行を追加します。
foozy@708: 
foozy@708: \interaction{daily.copy.other}
foozy@708: 
foozy@708: このリポジトリでは複製元の \filename{file} が変更されました。
foozy@708: 最初のリポジトリから変更内容を 
foozy@708: \hgcmd{pull} して２つの head をマージする際に Mercurial は、
foozy@708: \filename{file} に対してだけ行った変更内容を、
foozy@708: その複製である \filename{new-file} にまで伝播させます。
foozy@708: 
foozy@708: \interaction{daily.copy.merge}
foozy@708: 
foozy@708: \subsection{Why should changes follow copies?}
foozy@708: \label{sec:daily:why-copy}
foozy@708: 
foozy@708: ファイルの複製に対してる変更が伝播される挙動は、
foozy@708: 難解に思えるかもしれませんが、
foozy@708: 多くの場合は非常に好ましい振る舞いとなります。
foozy@708: 
foozy@708: まずは、
foozy@708: この伝播がマージの時\emph{だけ}に行われる、
foozy@708: ということに注意してください。
foozy@708: ファイルを \hgcmd{copy} で複製し、
foozy@708: それに引き続き複製元ファイルを変更する、
foozy@708: という通所の作業においては何も特別なことは行われません。
foozy@708: 
foozy@708: もう一点、
foozy@708: 変更を取り込んだリポジトリが、
foozy@708: ファイルを複製したことを\emph{知らなかった}場合に限り、
foozy@708: 変更内容が複製先ファイルに伝播する、
foozy@708: ということにも注意してください。
foozy@708: 
foozy@708: Mercurial がこのように振舞うのは以下のような理由のためです。
foozy@708: 例えば筆者が、
foozy@708: ソースファイルに対して重要なバグ修正を行い、
foozy@708: 変更内容をコミットしたとします。
foozy@708: その変更作業が行われている間に、
foozy@708: バグの顕在化やその修正を待つ事無く、
foozy@708: 当該ファイルを \hgcmd{copy} で複製し、
foozy@708: その複製先ファイルの変更を読者が始めてしまうかもしれません。
foozy@708: 
foozy@708: 読者が筆者の変更を取り込んでマージした際に、
foozy@708: Mercurial が複製への変更の反映を\emph{行わない}場合、
foozy@708: 読者の複製先ファイルはバグを含んでいるため、
foozy@708: 手動でバグ修正を反映させる必要性を思い出さない限り、
foozy@708: バグは複製先ファイルに\emph{残り続ける}でしょう。
foozy@708: 
foozy@708: バグ修正に関する変更内容の、
foozy@708: 複製元から複製先への自動反映により、
foozy@708: Mercurial はこの手の問題を回避しています。
foozy@708: 筆者の知る限り Mercurial は、
foozy@708: 複製ファイルに対するこのような変更伝播を行う\emph{唯一の}構成管理システムです。
foozy@708: 
foozy@708: ファイルの複製とそれに続くマージの実施が一旦変更履歴に記録されたなら、
foozy@708: 複製元ファイルから複製先ファイルへのそれ以上の変更反映は通常は不要なので、
foozy@708: Mercurial はマージ時点までは複製へ変更を伝播させますが、
foozy@708: それ以上は行いません。
foozy@708: 
foozy@708: \subsection{How to make changes \emph{not} follow a copy}
foozy@708: 
foozy@708: 仮に、何らかの理由により、
foozy@708: 複製ファイルへの自動的な変更反映が必要ないと判断したなら、
foozy@708: システムの通常の方法
foozy@708: （Unix 的なシステムの場合なら \command{cp}）
foozy@708: でファイルを複製し、
foozy@708: \hgcmd{add} により手動で複製ファイルを構成管理対象に追加してください。
foozy@708: ですが、その前に\ref{sec:daily:why-copy}節を読み直して、
foozy@708: Mercurial による自動変更反映の適切性を十分に検討してください。
foozy@708: 
foozy@708: \subsection{Behaviour of the \hgcmd{copy} command}
foozy@708: 
foozy@708: \hgcmd{copy} コマンドを使用した場合、
foozy@708: Mercurial は即座に作業領域ディレクトリに個々のファイルの複製を作成します。
foozy@708: そのため、
foozy@708: ファイルに修正を加えた後で、
foozy@708: その変更をチェンジセットとしてコミットすることなく
foozy@708: \hgcmd{copy} を行った場合、
foozy@708: 複製先ファイルはその時点までの変更内容も含んでいることになります
foozy@708: （この振る舞いについてここで述べたのは、
foozy@708: 少々直感に反するように感じられたからです）。
foozy@708: 
foozy@708: \hgcmd{copy} は
foozy@708: Unix の \command{cp} コマンドと同様に振舞います
foozy@708: （\hgcmd{cp} という別名方が好みであれば、こちらも使用できます）。
foozy@708: 末尾の引数は\emph{複製先}を、
foozy@708: それ以外の先行する引数は\emph{複製元}を意味します。
foozy@708: 複製元に単一のファイルを、
foozy@708: 複製先に存在しないパスを指定した場合、
foozy@708: Mercurial は複製先に指定した名前で新たなファイルを生成します。
foozy@708: 
foozy@708: \interaction{daily.copy.simple}
foozy@708: 
foozy@708: 複製先がディレクトリの場合、
foozy@708: Mercurial は複製元ファイルを当該ディレクトリに複製します。
foozy@708: 
foozy@708: \interaction{daily.copy.dir-dest}
foozy@708: 
foozy@708: ディレクトリの複製の場合は、
foozy@708: 再帰的且つディレクトリ構成を保持しつつ複製されます。
foozy@708: 
foozy@708: \interaction{daily.copy.dir-src}
foozy@708: 
foozy@708: 複製元と複製先の両方がディレクトリの場合\footnote{訳注:
foozy@708: 先の「ディレクトリの複製の場合」は、
foozy@708: 「複製先ディレクトリが存在しない場合」を指します。}、
foozy@708: 複製元のディレクトリ構造は、
foozy@708: 複製先ディレクトリ配下で再構築されます。
foozy@708: 
foozy@708: \interaction{daily.copy.dir-src-dest}
foozy@708: 
foozy@708: 手動でファイルを複製した後で、
foozy@708: 当該ファイルが複製であることを Mercurial に通知するには、
foozy@708: \hgcmd{remove} の場合と同様に、
foozy@708: \hgopt{copy}{--after} 付きで \hgcmd{copy} コマンドを使用します。
foozy@708: 
foozy@708: \interaction{daily.copy.after}
foozy@708: 
foozy@708: \section{Renaming files}
foozy@708: 
foozy@708: ファイルを複製するよりも、
foozy@708: むしろ改名の方が必要とされるのではないでしょうか。
foozy@708: ファイルの改名よりも
foozy@708: \hgcmd{copy} コマンドの方を先に説明したのは、
foozy@708: Mercurial が複製と改名を本質的には同等に扱っているためです。
foozy@708: そのため、
foozy@708: ファイルの複製における Mercurial の挙動を知ることで、
foozy@708: ファイルの改名で期待される振る舞いを知ることができます。
foozy@708: 
foozy@708: \hgcmd{rename} コマンドを使用した場合、
foozy@708: Mercurial は個々の改名元ファイルの複製を作成し、
foozy@708: その上で改名元ファイルを削除し、
foozy@708: それらを構成管理対象から除外します。
foozy@708: 
foozy@708: \interaction{daily.rename.rename}
foozy@708: 
foozy@708: \hgcmd{status} コマンドの出力から、
foozy@708: 新たに複製されたファイルが構成管理対象に追加され、
foozy@708: 改名元ファイルが除外されていることが読み取れます。
foozy@708: 
foozy@708: \interaction{daily.rename.status}
foozy@708: 
foozy@708: \hgcmd{copy} 実行の場合と同様に、
foozy@708: \hgopt{status}{-C} オプション付きで \hgcmd{status} コマンドを実行することで、
foozy@708: 構成管理対象に追加されたファイルが実際には、
foozy@708: 今は削除されてしまったファイルの複製ファイル、
foozy@708: と Mercurial にみなされていることがわかります。
foozy@708: 
foozy@708: \interaction{daily.rename.status-copy}
foozy@708: 
foozy@708: \hgcmd{remove} および \hgcmd{copy} と同様に、
foozy@708: \hgopt{rename}{--after} オプションを指定することで、
foozy@708: 実際に改名した後で Mercurial にその旨を通知することができます。
foozy@708: それ以外の殆どの点で、
foozy@708: \hgcmd{rename} コマンドの振る舞い並びに指定可能なオプションは、
foozy@708: \hgcmd{copy} コマンドと同じです。
foozy@708: 
foozy@708: \subsection{Renaming files and merging changes}
foozy@708: 
foozy@708: Mercurial の改名が「複製と削除」として実装されているため、
foozy@708: 複製の後でのマージの場合と同様に、
foozy@708: 改名の後でマージをした場合には変更が伝播されます。
foozy@708: 
foozy@708: あるユーザがファイルを修正し、
foozy@708: 別のユーザがそのファイルを別なファイルに改名した場合、
foozy@708: 両者がお互いの変更をマージすると、
foozy@708: 一方が行った改名元ファイルへの修正は改名先ファイルへと伝播します
foozy@708: （この振る舞いは``普通の作業''で期待するであろう類のものですが、
foozy@708: 全ての構成管理システムがこのように振舞うわけではありません）。
foozy@708: 
foozy@708: 複製先に対する変更の伝播が、
foozy@708: 利用者にとっておそらく有用と思われる機能ですから、
foozy@708: ファイルの改名においても変更の伝播が重要であろうことは、
foozy@708: 明らかといえるでしょう。
foozy@708: 変更伝播機能が無い場合、
foozy@708: ファイルの改名によって変更は簡単に行く先を失ってしまうことでしょう。
foozy@708: 
foozy@708: \subsection{Divergent renames and merging}
foozy@708: 
foozy@708: 名前の広がり（diverging names）は、
foozy@708: 二人の開発者がとあるファイル---
foozy@708: これを \filename{foo} と呼びます---
foozy@708: を各自のリポジトリで扱うことで発生します。
foozy@708: 
foozy@708: \interaction{rename.divergent.clone}
foozy@708: 
foozy@708: Anne がファイルを \filename{bar} に改名します。
foozy@708: 
foozy@708: \interaction{rename.divergent.rename.anne}
foozy@708: 
foozy@708: その一方で、Bob がファイルを \filename{quux} に改名します。
foozy@708: 
foozy@708: \interaction{rename.divergent.rename.bob}
foozy@708: 
foozy@708: 個々の開発者がファイルの命名に関する異なる意向を表明したわけですから、
foozy@708: 筆者はこの事態を衝突と捉えるのが良いと思います。
foozy@708: 
foozy@708: この場合のマージはどのように振舞うべきだと思いますか？
foozy@708: 改名による枝分かれが生じるチェンジセットのマージの場合、
foozy@708: Merging は常に\emph{両方}の改名先ファイルを維持します。
foozy@708: 
foozy@708: \interaction{rename.divergent.merge}
foozy@708: 
foozy@708: 筆者個人にとってこの振る舞いは大変意外であり、
foozy@708: それがここでこの振る舞いを説明している理由でもあります。
foozy@708: 筆者は Mercurial に、
foozy@708: \filename{bar} を残すか、
foozy@708: \filename{quux} を残すか、
foozy@708: あるいは両方を残すか、
foozy@708: という選択肢による確認を行うことを期待していたのです。
foozy@708: 
foozy@708: 実際には、
foozy@708: ファイルの改名を行った場合、
foozy@708: 改名元ファイルを使用したビルドを行う他のファイル
foozy@708: （例えば makefile）の修正が行われるであろうことを意味します。
foozy@708: そのため、
foozy@708: Anne がファイルを改名し、
foozy@708: 改名後のファイルでビルドが実施されるように
foozy@708: \filename{Makefile} を修正した場合、
foozy@708: 一方で Bob が同様の修正を別な名前で行っていますから、
foozy@708: マージの際には作業領域ディレクトリに異なる名前のファイルのコピーが存在し、
foozy@708: \emph{且つ} Anne と Bob の
foozy@708: \filename{Makefile} への修正箇所が衝突している筈です。
foozy@708: 
foozy@708: 他の利用者もこの振る舞いに意外性を感じているようです。
foozy@708: 詳細は \bug{455} を参照してください。
foozy@708: 
foozy@708: \subsection{Convergent renames and merging}
foozy@708: 
foozy@708: 異なる\emph{複製元}ファイルが同じファイルを\emph{複製先}とした際に、
foozy@708: 改名による別な種類の衝突が発生します。
foozy@708: この場合、Mercurial は通常のマージ機構を使用し、
foozy@708: 適切な解決への誘導を要求してきます。
foozy@708: 
foozy@708: \subsection{Other name-related corner cases}
foozy@708: 
foozy@708: Mercurial は、
foozy@708: 一方がファイルに使用した名前を他方がディレクトリに使用した場合に、
foozy@708: マージが失敗するバグが長い間残っています。
foozy@708: この問題は \bug{29} に詳細があります。
foozy@708: 
foozy@708: \interaction{issue29.go}
foozy@708: 
foozy@708: \section{Recovering from mistakes}
foozy@708: 
foozy@708: 幾つかのありがちな間違いから復旧するために、
foozy@708: Mercurial は有用なコマンドを幾つか提供しています。
foozy@708: 
foozy@708: \hgcmd{revert} コマンドは、
foozy@708: 作業領域ディレクトリに対する変更を取り消します。
foozy@708: 例えば、うっかりファイルを \hgcmd{add} してしまった場合に、
foozy@708: 追加してしまったファイル名を指定して
foozy@708: \hgcmd{revert} を実行することで、
foozy@708: ファイルには一切変更を加える事無く
foozy@708: Mercurial による構成管理対象から除外することができます。
foozy@708: ファイルへの間違った変更を取り消すのにも
foozy@708: \hgcmd{revert} が利用できます。
foozy@708: 
foozy@708: \hgcmd{revert} コマンドは未コミットな変更に対して有効である、
foozy@708: ということは憶えておきましょう。
foozy@708: 但し、
foozy@708: 一旦変更をコミットした後で変更内容が間違いであることに気が付いた場合でも、
foozy@708: 選択肢は限られてはいますが対処することはできます。
foozy@708: 
foozy@708: \hgcmd{revert} コマンドに関する詳細と、
foozy@708: コミット済みの変更に関する対処の詳細に関しては、
foozy@708: \ref{chap:undo}~章を参照してください。
foozy@708: 
foozy@708: %%% Local Variables: 
foozy@708: %%% mode: latex
foozy@708: %%% TeX-master: "00book"
foozy@708: %%% End: