%\chapter{A tour of Mercurial: merging work}
\chapter{Mercurialツアー: マージ}
\label{chap:tour-merge}

%We've now covered cloning a repository, making changes in a
%repository, and pulling or pushing changes from one repository into
%another.  Our next step is \emph{merging} changes from separate
%repositories.

我々は既にリポジトリのクローン，リポジトリに対する変更，1つのリポジトリか
らのpullと別の1つのリポジトリに対するpushを行った．次のステップは別のリポ
ジトリから変更を\emph{マージ}することである．

%\section{Merging streams of work}
\section{複数の作業結果をマージする}

%Merging is a fundamental part of working with a distributed revision
%control tool.

マージは分散リビジョンコントロールツールでの作業において不可欠の部分であ
る．

\begin{itemize}
%\item Alice and Bob each have a personal copy of a repository for a

%  project they're collaborating on.  Alice fixes a bug in her
%  repository; Bob adds a new feature in his.  They want the shared
%  repository to contain both the bug fix and the new feature.
 \item アリスとボブは共同作業しているプロジェクトのリポジトリコピーを各々
持っている．アリスは自分のリポジトリでバグを修正し，ボブは彼のリポジトリ
で新機能を追加した．彼らはバグ修正と新機能の両方を持つリポジトリを共有し
たいと考えている．

%\item I frequently work on several different tasks for a single
%  project at once, each safely isolated in its own repository.
%  Working this way means that I often need to merge one piece of my
%  own work with another.
 \item 私は一つのプロジェクトの別々のタスクに対して同時に作業を行うことを
       よく行っている．このような作業スタイルでは，自分の作業の一つから別
       の作業の一つへ結果をマージしたいと思うことがしばしばある．

\end{itemize}

%Because merging is such a common thing to need to do, Mercurial makes
%it easy.  Let's walk through the process.  We'll begin by cloning yet
%another repository (see how often they spring up?) and making a change
%in it.

上で述べたようにマージを行いたい状況はとても多いため， Mercurialではマー
ジを簡単に行えるようになっている．まず別のリポジトリをクローンし，変更を
加えるところから始めよう．
\interaction{tour.merge.clone}

%We should now have two copies of \filename{hello.c} with different
%contents.  The histories of the two repositories have also diverged,
%as illustrated in figure~\ref{fig:tour-merge:sep-repos}.

今，内容の異なった2つの\filename{hello.c}がある． 2つのリポジトリの履歴は
図~\ref{fig:tour-merge:sep-repos}に示すように分かれている．
\interaction{tour.merge.cat}

\begin{figure}[ht]
  \centering
  \grafix{tour-merge-sep-repos}
%  \caption{Divergent recent histories of the \dirname{my-hello} and
%    \dirname{my-new-hello} repositories}
  \caption{\dirname{my-hello}リポジトリと\dirname{my-new-hello}リポジト
 リの履歴の差異}
  \label{fig:tour-merge:sep-repos}
\end{figure}

%We already know that pulling changes from our \dirname{my-hello}
%repository will have no effect on the working directory.
既に\dirname{my-hello}リポジトリからのpullはワーキングディレクトリに何の
影響も与えないことを学んだ．
\interaction{tour.merge.pull}
%However, the \hgcmd{pull} command says something about ``heads''.
しかし\hgcmd{pull}コマンドは``heads''についてメッセージを表示する．

%\subsection{Head changesets}
\subsection{Headチェンジセット}

%A head is a change that has no descendants, or children, as they're
%also known.  The tip revision is thus a head, because the newest
%revision in a repository doesn't have any children, but a repository
%can contain more than one head.
headは子やその子孫を持たない変更である．リポジトリの最新のリビジョンは子
を持たないため，tipリビジョンはすなわちheadである．一方でリポジトリは複数
のheadを持ち得る．

\begin{figure}[ht]
  \centering
  \grafix{tour-merge-pull}
%  \caption{Repository contents after pulling from \dirname{my-hello} into
%    \dirname{my-new-hello}}
  \caption{\dirname{my-hello}から\dirname{my-new-hello}へpullしたあとの
 リポジトリの内容}
  \label{fig:tour-merge:pull}
\end{figure}

%In figure~\ref{fig:tour-merge:pull}, you can see the effect of the
%pull from \dirname{my-hello} into \dirname{my-new-hello}.  The history
%that was already present in \dirname{my-new-hello} is untouched, but a
%new revision has been added.  By referring to
%figure~\ref{fig:tour-merge:sep-repos}, we can see that the
%\emph{changeset ID} remains the same in the new repository, but the
%\emph{revision number} has changed.  (This, incidentally, is a fine
%example of why it's not safe to use revision numbers when discussing
%changesets.)  We can view the heads in a repository using the
%\hgcmd{heads} command.
%\interaction{tour.merge.heads}

図~\ref{fig:tour-merge:pull}に\dirname{my-hello}から
\dirname{my-new-hello}へpullを行った効果を示す． \dirname{my-new-hello}に
既に存在した履歴は変更されず，新たにリビジョンが追加される．
figure~\ref{fig:tour-merge:sep-repos}を見ると，新しいリポジトリにも
\emph{changeset ID}が残っていること，\emph{リビジョン番号}が変更されてい
ることが分かる． （これは同時にチェンジセットについて論じる際にリビジョン
番号を用いるのが安全でないことの例になっている．）リポジトリ内にあるhead
は\hgcmd{heads}によって見ることができる．
\interaction{tour.merge.heads}

%\subsection{Performing the merge}
\subsection{マージを実行する}

%What happens if we try to use the normal \hgcmd{update} command to
%update to the new tip?
%\interaction{tour.merge.update}

新しいtipへ更新するために\hgcmd{update}を使った場合何が起きるか？
\interaction{tour.merge.update}

%Mercurial is telling us that the \hgcmd{update} command won't do a
%merge; it won't update the working directory when it thinks we might
%want to do a merge, unless we force it to do so.  Instead, we
%use the \hgcmd{merge} command to merge the two heads.
%\interaction{tour.merge.merge}

Mercurialは\hgcmd{update}コマンドがマージを行わないとメッセージを表示す
る． \hgcmd{update}コマンドは，マージが必要と考えられる場合は，ユーザが
（オプションによって）強制しない限りワーキングディレクトリを更新しない．
一方，\hgcmd{merge}コマンドは2つのヘッドのマージを行う．
\interaction{tour.merge.merge}

%This updates the working directory so that it contains changes from
%\emph{both} heads, which is reflected in both the output of
%\hgcmd{parents} and the contents of \filename{hello.c}.
%\interaction{tour.merge.parents}

この操作によって\hgcmd{parents}と\filename{hello.c}の出力の双方を反映する
\emph{双方の}headからの変更を含むようにワーキングディレクトリが更新される．

%\subsection{Committing the results of the merge}
\subsection{マージ結果をコミットする}

%Whenever we've done a merge, \hgcmd{parents} will display two parents
%until we \hgcmd{commit} the results of the merge.
%\interaction{tour.merge.commit}

マージを行うと，マージの結果を\hgcmd{commit}するまで，\hgcmd{parents}は
親2つを表示する．
\interaction{tour.merge.commit}

%We now have a new tip revision; notice that it has \emph{both} of
%our former heads as its parents.  These are the same revisions that
%were previously displayed by \hgcmd{parents}.
%\interaction{tour.merge.tip}

新しいtipリビジョンは以前のヘッド\emph{両方}を親として持つ．これらは
\hgcmd{parents}コマンドで表示したのと同じリビジョンである．
\interaction{tour.merge.tip}

%In figure~\ref{fig:tour-merge:merge}, you can see a representation of
%what happens to the working directory during the merge, and how this
%affects the repository when the commit happens.  During the merge, the
%working directory has two parent changesets, and these become the
%parents of the new changeset.

図~\ref{fig:tour-merge:merge}で，マージの間にワーキングディレクトリに何が
起き，コミットした時にリポジトリにどう影響するのかを見ることができる．
マージの間，ワーキングディレクトリは2つの親チェンジセットを持ち，これらは
新しいチェンジセットの両親となる．

\begin{figure}[ht]
  \centering
  \grafix{tour-merge-merge}
%  \caption{Working directory and repository during merge, and
%    following commit}
  \caption{マージ中のワーキングディレクトリとリポジトリおよび後続のコミッ
 ト}
  \label{fig:tour-merge:merge}
\end{figure}

%We sometimes talk about a merge having \emph{sides}: the left side is
%the first parent in the output of \hgcmd{parents}, and the right side is
%the second.  If the working directory was at e.g. revision 5 before we
%began a merge, that revision will become the left side of the merge.

マージにより\emph{サイド}ができることがある．左のサイドは\hgcmd{parents}
の出力の最初の親で，右のサイドが2番目の親である．例えば，マージ前にワーキ
ングディレクトリがリビジョン5であったとすると，マージの左のサイドがこの
リビジョンになる．

%\section{Merging conflicting changes}
\section{コンフリクトのある変更をマージする}

%Most merges are simple affairs, but sometimes you'll find yourself
%merging changes where each side modifies the same portions of the same
%files.  Unless both modifications are identical, this results in a
%\emph{conflict}, where you have to decide how to reconcile the
%different changes into something coherent.

大半のマージはシンプルなものだが，同じファイルの同じ箇所を変更するチェン
ジセットをマージしなければならないこともある．各々の変更が同じ内容でない
限り，結果は\emph{conflict}となるため，変更を整合させるように修正する必要
がある．

\begin{figure}[ht]
  \centering
  \grafix{tour-merge-conflict}
%  \caption{Conflicting changes to a document}
  \caption{コンフリクトしたチェンジセット}
  \label{fig:tour-merge:conflict}
\end{figure}

%Figure~\ref{fig:tour-merge:conflict} illustrates an instance of two
%conflicting changes to a document.  We started with a single version
%of the file; then we made some changes; while someone else made
%different changes to the same text.  Our task in resolving the
%conflicting changes is to decide what the file should look like.

1つのドキュメントに対して2つのチェンジセットがコンフリクトした様子を
図~\ref{fig:tour-merge:conflict}に示す．

ここでは，ある1つのバージョンのファイルにいくつかの変更を加え，同時に別の
人が別の変更を同じテキストに対して加えている．チェンジセットのコンフリク
トを解決するため，ファイルがどうあるべきかを明らかにしよう．

%Mercurial doesn't have a built-in facility for handling conflicts.
%Instead, it runs an external program, usually one that displays some
%kind of graphical conflict resolution interface.  By default, Mercurial
%tries to find one of several different merging tools that are likely to
%be installed on your system.  It first tries a few fully automatic
%merging tools; if these don't succeed (because the resolution process
%requires human guidance) or aren't present, it tries a few different
%graphical merging tools.

Mercurialは内蔵のコンフリクト解決機構を持たない．その代わり，何らかのグラ
フィカルなコンフリクト解決インタフェースを表示する外部コマンドを起動す
る．デフォルトでMercurialはシステムにインストールされている可能性の高いい
くつかのマージツールを捜す．Mercurialは最初に2,3の全自動のマージツールを
試す．これでうまくいかない場合（解決プロセスに人のガイドが必要な場合）や
ツールが存在しない場合，スクリプトは別の2,3のグラフィカルマージツールを試
す．

%It's also possible to get Mercurial to run another program or script
%instead of \command{hgmerge}, by setting the \envar{HGMERGE}
%environment variable to the name of your preferred program.

環境変数\envar{HGMERGE}に好みのプログラム名をを設定することで，Mercurial
が\command{hgmerge}以外のスクリプトを起動するようにすることも可能である．

%\subsection{Using a graphical merge tool}
\subsection{グラフィカルマージツールの使用}

%My preferred graphical merge tool is \command{kdiff3}, which I'll use
%to describe the features that are common to graphical file merging
%tools.  You can see a screenshot of \command{kdiff3} in action in
%figure~\ref{fig:tour-merge:kdiff3}.  The kind of merge it is
%performing is called a \emph{three-way merge}, because there are three
%different versions of the file of interest to us.  The tool thus
%splits the upper portion of the window into three panes:

筆者の好みのグラフィカルマージツールは\command{kdiff3}なので，これを使っ
てグラフィカルファイルマージツールの機能を説明する．
図~\ref{fig:tour-merge:kdiff3}に\command{kdiff3}の実際の動作のスクリーン
ショットを示す．今注目しているファイルには3つの異なったバージョンがあるた
め，ここで実行されているのは\emph{3wayマージ}である．ツールはウィンドウの
上部を3つのペーンに分割している．

\begin{itemize}
%\item At the left is the \emph{base} version of the file, i.e.~the
%  most recent version from which the two versions we're trying to
%  merge are descended.
 \item 左にあるのはファイルの\emph{ベース}バージョンである．これはこれか
       らマージしようとする2つのバージョンの親となる最も新しいバージョン
       である．

%\item In the middle is ``our'' version of the file, with the contents
%  that we modified.
 \item 中央にあるのは我々が変更を加えたバージョンである．

%\item On the right is ``their'' version of the file, the one that
%  from the changeset that we're trying to merge with.
 \item 右にあるのは他の人が変更を加えたバージョンで，これからマージしよ
       うとするものである．
\end{itemize}

%In the pane below these is the current \emph{result} of the merge.
%Our task is to replace all of the red text, which indicates unresolved
%conflicts, with some sensible merger of the ``ours'' and ``theirs''
%versions of the file.

この下のペーンにはマージの\emph{結果}がある．赤字の行はコンフリクトを示し
ており，我々のバージョンと他の人のバージョンを注意深くマージした結果を用
いてこれらをすべて置き換える．

%All four of these panes are \emph{locked together}; if we scroll
%vertically or horizontally in any of them, the others are updated to
%display the corresponding sections of their respective files.

4つのペーンすべては\emph{同期}しており、どれかを垂直または水平にスクロー
ルすると、他の3つも対応する箇所を表示するように更新される。

\begin{figure}[ht]
  \centering
  \grafix{kdiff3}
%  \caption{Using \command{kdiff3} to merge versions of a file}
  \caption{ファイルの複数リビジョンを\command{kdiff3}を使ってマージする}
  \label{fig:tour-merge:kdiff3}
\end{figure}

%For each conflicting portion of the file, we can choose to resolve
%the conflict using some combination of text from the base version,
%ours, or theirs.  We can also manually edit the merged file at any
%time, in case we need to make further modifications.

コンフリクトを解決するために，ファイル中のコンフリクトしているすべての部
分に対してベースバージョン，我々のバージョン，別の人々のバージョンのテキ
ストを組み合わせて用いる．さらなる修正が必要な場合は，マージされたファイ
ルを手動で編集することもできる．

%There are \emph{many} file merging tools available, too many to cover
%here.  They vary in which platforms they are available for, and in
%their particular strengths and weaknesses.  Most are tuned for merging
%files containing plain text, while a few are aimed at specialised file
%formats (generally XML).

\emph{数々の}マージツールが利用可能であり，それらをカバーすることはできな
い．それらは，利用可能なプラットフォームが異なり，それぞれ長所と弱点が異
なる．ほとんどがプレーンテキストをマージするように作られているが，特別な
ファイルフォーマット（XML）に特化しているものもある．

%\subsection{A worked example}
\subsection{実行例}

%In this example, we will reproduce the file modification history of
%figure~\ref{fig:tour-merge:conflict} above.  Let's begin by creating a
%repository with a base version of our document.
%\interaction{tour-merge-conflict.wife}
%We'll clone the repository and make a change to the file.
%\interaction{tour-merge-conflict.cousin}
%And another clone, to simulate someone else making a change to the
%file.  (This hints at the idea that it's not all that unusual to merge
%with yourself when you isolate tasks in separate repositories, and
%indeed to find and resolve conflicts while doing so.)
%\interaction{tour-merge-conflict.son}
%Having created two different versions of the file, we'll set up an
%environment suitable for running our merge.
%\interaction{tour-merge-conflict.pull}

この例では前述の図~\ref{fig:tour-merge:conflict}での変更履歴を再現する．
文書のベースバージョンを含むリポジトリを作成することから始める．
\interaction{tour-merge-conflict.wife}
リポジトリをコピーし，ファイルに変更を行う．
\interaction{tour-merge-conflict.cousin}
別の人が変更を行うのをシミュレートするためにもう一つのクローンを作成す
る．（別々のリポジトリに隔離して行った作業の結果をマージし，コンフリクト
を解消することは少しも珍しいことではないという事がわかるだろう． ）
\interaction{tour-merge-conflict.son}
ファイルに2つの別のバージョンを作り，マージを行うのに的下環境を設定する．
\interaction{tour-merge-conflict.pull}

%In this example, I'll set \envar{HGMERGE} to tell Mercurial to use the
%non-interactive \command{merge} command.  This is bundled with many
%Unix-like systems. (If you're following this example on your computer,
%don't bother setting \envar{HGMERGE}.)

この例では\envar{HGMERGE}を設定して，Mercurialに非対話的な
\command{merge}コマンドを起動させる．これは多くのUnix系システムにバンドル
されているコマンドである．（この例を手元のマシンで実行する時には
\envar{HGMERGE}を設定する必要はない．）

%Mercurial can tell from the way \command{merge} exits that it wasn't
%able to merge successfully, so it tells us what commands we'll need to
%run if we want to redo the merging operation.  This could be useful
%if, for example, we were running a graphical merge tool and quit
%because we were confused or realised we had made a mistake.

Mercurialは\command{merge}コマンドで正しくマージできなかった場合，もう一
度マージを行うためにどのようにすればいいのかを表示する．これは，グラフィ
カルマージツールの使用中に混乱を来したか間違いを犯したことに気付いたため
に終了した場合などに有効であろう．

%If automatic or manual merges fail, there's nothing to prevent us from
%``fixing up'' the affected files ourselves, and committing the results
%of our merge:
%\interaction{tour-merge-conflict.commit}

自動または手動によるマージが失敗した場合，影響を受けるファイルを``修正''
してマージの結果をコミットしなければならない．
\interaction{tour-merge-conflict.commit}


%\section{Simplifying the pull-merge-commit sequence}
\section{pull-merge-commit手順を簡単にする}
\label{sec:tour-merge:fetch}

%The process of merging changes as outlined above is straightforward,
%but requires running three commands in sequence.
前節で概要を述べたチェンジセットのマージプロセスは単純なものだったが，3
つのコマンドを順に用いる必要があった．

\begin{codesample2}
  hg pull -u
  hg merge
  hg commit -m 'Merged remote changes'
\end{codesample2}
%In the case of the final commit, you also need to enter a commit
%message, which is almost always going to be a piece of uninteresting
%``boilerplate'' text.
最後のコミットでは，ほとんど退屈なボイラープレートテキストと言ってもよい
コミットメッセージの入力も必要であった．

%It would be nice to reduce the number of steps needed, if this were
%possible.  Indeed, Mercurial is distributed with an extension called
%\hgext{fetch} that does just this.

可能であれば必要なステップ数を少なくすることができるとよい．実は
Mercurialは\hgext{fetch}という，まさにこのことを行うエクステンションを同
梱している．

%Mercurial provides a flexible extension mechanism that lets people
%extend its functionality, while keeping the core of Mercurial small
%and easy to deal with.  Some extensions add new commands that you can
%use from the command line, while others work ``behind the scenes,''
%for example adding capabilities to the server.

Mercurialはコアを小さく，扱いやすく保ったまま機能を拡張できる柔軟なエクス
テンションメカニズムを提供している．コマンドラインから利用できる新しいコ
マンドを追加するようなエクステンションもあれば，目に見えないところで例え
ばサーバに機能を追加するようなものもある．

%The \hgext{fetch} extension adds a new command called, not
%surprisingly, \hgcmd{fetch}.  This extension acts as a combination of
%\hgopt{pull}{-u}, \hgcmd{merge} and \hgcmd{commit}. It begins by pulling
%changes from another repository into the current repository.  If it
%finds that the changes added a new head to the repository, it
%begins a merge, then (if the merge succeeded) commits the result
%of the merge with an automatically-generated commit message.  If
%no new heads were added, it updates the working directory to the
%new tip changeset.

\hgext{fetch}エクステンションはその名の通りの新しいコマンド\hgcmd{fetch}
を追加する．このエクステンションは\hgopt{pull}{-u}と\hgcmd{merge}および
\hgcmd{commit}を組み合わせた働きをする．このエクステンションはまず他のリ
ポジトリから変更をpullし，リポジトリに新しいヘッドが追加された場合はマー
ジを行い，（マージが成功した場合）マージ結果を自動的に生成されたコミット
メッセージと共にコミットする．新たなヘッドが追加されなかった場合は新たな
tipチェンジセットへワーキングディレクトリを更新する．

%Enabling the \hgext{fetch} extension is easy.  Edit the
%\sfilename{.hgrc} in your home directory, and either go to the
%\rcsection{extensions} section or create an \rcsection{extensions}
%section.  Then add a line that simply reads ``\Verb+fetch +''.

\hgext{fetch}エクステンションは簡単に有効にすることができる．ホームディレ
クトリの\sfilename{.hgrc}ファイルを編集し，\rcsection{extensions}セクショ
ンに``\Verb+fetch +''という行を追加すればよい．
\begin{codesample2}
  [extensions]
  fetch =
\end{codesample2}
%(Normally, the right-hand side of the ``\texttt{=}'' would indicate
%where to find the extension, but since the \hgext{fetch} extension is in
%the standard distribution, Mercurial knows where to search for it.)
（通常，右辺の``\texttt{=}''はエクステンションの置かれた場所を表す
が，\hgext{fetch}エクステンションは標準配布物に含まれるため，Mercurialは
その所在をすでに知っている．）

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