%\chapter{Finding and fixing your mistakes}
\chapter{ミスの発見と修正}
\label{chap:undo}

%To err might be human, but to really handle the consequences well
%takes a top-notch revision control system.  In this chapter, we'll
%discuss some of the techniques you can use when you find that a
%problem has crept into your project.  Mercurial has some highly
%capable features that will help you to isolate the sources of
%problems, and to handle them appropriately.

リビジョンコントロールシステムには人の犯した間違いをうまく処理する機能が
求められている．この章では，プロジェクトに起こり得る問題の解決に利用可能
なテクニックについて述べる．Mercurialには問題のあるソースを切り分け，処理
する強力な機能がある．


%\section{Erasing local history}
\section{ローカルヒストリーを消去する}

%\subsection{The accidental commit}
\subsection{アクシデントによるコミット}

%I have the occasional but persistent problem of typing rather more
%quickly than I can think, which sometimes results in me committing a
%changeset that is either incomplete or plain wrong.  In my case, the
%usual kind of incomplete changeset is one in which I've created a new
%source file, but forgotten to \hgcmd{add} it.  A ``plain wrong''
%changeset is not as common, but no less annoying.

筆者にはタイピング中に考えるよりも先に指が動いてしまう癖が以前からあり，
たまにこれが起きると，不完全だったり間違った内容のチェンジセットをコミッ
トしてしまう．筆者の場合，不完全なチェンジセットの典型は新しいソースファ
イルを作成したのに\hgcmd{add}を忘れることで，``間違った内容''のコミット
はあまり起きないが，やはり同じように厄介である．


%\subsection{Rolling back a transaction}
\subsection{トランザクションのロールバック}
\label{sec:undo:rollback}

%In section~\ref{sec:concepts:txn}, I mentioned that Mercurial treats
%each modification of a repository as a \emph{transaction}.  Every time
%you commit a changeset or pull changes from another repository,
%Mercurial remembers what you did.  You can undo, or \emph{roll back},
%exactly one of these actions using the \hgcmd{rollback} command.  (See
%section~\ref{sec:undo:rollback-after-push} for an important caveat
%about the use of this command.)

\ref{sec:concepts:txn}節で，Mercurialはリポジトリへの個々の変更を\emph{ト
ランザクション}として扱うということを述べた．Mercurialは，別のリポジトリ
へのチェンジセットのコミットや変更のpullを記憶している．ユーザはundoした
り，一回に限りアクションを\hgcmd{rollback}コマンドで\emph{ロールバック}す
ることができる．(このコマンドの重要な制約については
\ref{sec:undo:rollback-after-push}を参照のこと．)


%Here's a mistake that I often find myself making: committing a change
%in which I've created a new file, but forgotten to \hgcmd{add} it.
%\interaction{rollback.commit}
%Looking at the output of \hgcmd{status} after the commit immediately
%confirms the error.
%\interaction{rollback.status}
%The commit captured the changes to the file \filename{a}, but not the
%new file \filename{b}.  If I were to push this changeset to a
%repository that I shared with a colleague, the chances are high that
%something in \filename{a} would refer to \filename{b}, which would not
%be present in their repository when they pulled my changes.  I would
%thus become the object of some indignation.

筆者が良く起こすミスは，新しいファイルを作成したチェンジセットをコミット
する時に\hgcmd{add}の実行を忘れるものである．
\interaction{rollback.commit}
コミット後の\hgcmd{status}の出力を見ると，直ちにエラーを表示していること
がわかる．
\interaction{rollback.status}
コミットは\filename{a}への変更を含んでいるが，\filename{b}への変更は含ん
でいない．ここで私が同僚と共有しているリポジトリへチェンジセットのプッシュ
を行ったとしたら，彼らが変更をプルした時，\filename{a}の中の何かが彼ら
のリポジトリに含まれない\filename{b}への参照を行う可能性は高い．そうなっ
たら筆者は同僚の怒りを買うことになるだろう．

%However, luck is with me---I've caught my error before I pushed the
%changeset.  I use the \hgcmd{rollback} command, and Mercurial makes
%that last changeset vanish.
%\interaction{rollback.rollback}
%Notice that the changeset is no longer present in the repository's
%history, and the working directory once again thinks that the file
%\filename{a} is modified.The commit and rollback have left the
%working directory exactly as it was prior to the commit; the changeset
%has been completely erased.  I can now safely \hgcmd{add} the file
%\filename{b}, and rerun my commit.
%\interaction{rollback.add}

しかし好運にもチェンジセットをプッシュする前にエラーに気づいた場合，
\hgcmd{rollback}コマンドを使用することでMercurialから最後の更新を取り除
くことができる．
\interaction{rollback.rollback}
チェンジセットはリポジトリの履歴にもはや存在せず，ワーキングディレクトリ
の\filename{a}は変更されたと認識される．コミットしてロールバックすると，
ワーキングディレクトリは完全にコミット前の状態になり，チェンジセットは完
全に消去される．この状態で安全に\hgcmd{add} \filename{b}し，もう一度
commitすることができる．
\interaction{rollback.rollback}

%\subsection{The erroneous pull}
\subsection{誤ったプル}

%It's common practice with Mercurial to maintain separate development
%branches of a project in different repositories.  Your development
%team might have one shared repository for your project's ``0.9''
%release, and another, containing different changes, for the ``1.0''
%release.

Mercurialを使って別々の開発ブランチを別々のリポジトリで管理することがよく
ある．あなたの開発チームはプロジェクトのリリース0.9のために1つの共有リポ
ジトリを持ち，リリース1.0のために異なる変更を持ったもう一つ別のリポジト
リをもっている．

%Given this, you can imagine that the consequences could be messy if
%you had a local ``0.9'' repository, and accidentally pulled changes
%from the shared ``1.0'' repository into it.  At worst, you could be
%paying insufficient attention, and push those changes into the shared
%``0.9'' tree, confusing your entire team (but don't worry, we'll
%return to this horror scenario later).  However, it's more likely that
%you'll notice immediately, because Mercurial will display the URL it's
%pulling from, or you will see it pull a suspiciously large number of
%changes into the repository.

ここであなたは誤ってローカルの0.9リポジトリに共有1.0リポジトリからプルし
たとする．最悪の場合，注意を怠って，これを共有の0.9リポジトリに書き戻して
しまい，開発チーム全体を混乱させてしまうことが有り得る．（この場合どうす
ればいいのかについては後述する．）実際には，Mercurialはpull元のURLを表示
するし，間違ったリポジトリからpullすれば大量のチェンジセットが表示される
ため，即座に何かがおかしいと気づくことだろう．

%The \hgcmd{rollback} command will work nicely to expunge all of the
%changesets that you just pulled.  Mercurial groups all changes from
%one \hgcmd{pull} into a single transaction, so one \hgcmd{rollback} is
%all you need to undo this mistake.

\hgcmd{rollback}コマンドを実行すれば，今プルしたばかりのチェンジセットを
全て消去することができる．Mercurialは一回\hgcmd{pull}によるトランザクショ
ンでもたらされた全てのチェンジセットをグループ化しているので，
\hgcmd{rollback}を一度実行するだけで，ミスを全てやり直すことができる．


%\subsection{Rolling back is useless once you've pushed}
\subsection{一度プッシュした後ではロールバックできない}
\label{sec:undo:rollback-after-push}

%The value of the \hgcmd{rollback} command drops to zero once you've
%pushed your changes to another repository.  Rolling back a change
%makes it disappear entirely, but \emph{only} in the repository in
%which you perform the \hgcmd{rollback}.  Because a rollback eliminates
%history, there's no way for the disappearance of a change to propagate
%between repositories.

他のリポジトリに変更をプッシュした後では\hgcmd{rollback}の価値はゼロであ
る．変更をロールバックすることによって変更は完全に消滅するが，それはあな
たが\hgcmd{rollback}を実行したリポジトリに限ってのことである．ロールバッ
クによって（変更の）履歴自体がなかったことになるので，変更の消滅を他のリ
ポジトリに波及させる手段はない．

%If you've pushed a change to another repository---particularly if it's a
%shared repository---it has essentially ``escaped into the wild,'' and
%you'll have to recover from your mistake in a different way.  What will
%happen if you push a changeset somewhere, then roll it back, then pull
%from the repository you pushed to, is that the changeset will reappear
%in your repository.

もしあなたが他のリポジトリ（特に共有リポジトリ）に変更をプッシュしている
のなら，困った事態が起こっており，別の方法でミスから復旧する必要がある．
チェンジセットをどこかへプッシュした後でロールバックし，プッシュ先のリポ
ジトリから再びプルした場合，チェンジセットがローカルリポジトリに再び現れ
る．

%(If you absolutely know for sure that the change you want to roll back
%is the most recent change in the repository that you pushed to,
%\emph{and} you know that nobody else could have pulled it from that
%repository, you can roll back the changeset there, too, but you really
%should really not rely on this working reliably.  If you do this,
%sooner or later a change really will make it into a repository that
%you don't directly control (or have forgotten about), and come back to
%bite you.)

（もしロールバックしたいチェンジセットがプッシュ先のリポジトリで最新であ
り，かつ，誰もそれをプルしていないことが確実である場合は，プッシュ先のリ
ポジトリでロールバックすることが可能だが，この方法は確実ではないというこ
とを肝に命じておくべきである．この方法は直接コントロールできなかったり，
その方法を忘れてしまったリポジトリへの変更の修正には使えない．）


%\subsection{You can only roll back once}
\subsection{ロールバックは一回のみ}

%Mercurial stores exactly one transaction in its transaction log; that
%transaction is the most recent one that occurred in the repository.
%This means that you can only roll back one transaction.  If you expect
%to be able to roll back one transaction, then its predecessor, this is
%not the behaviour you will get.
%\interaction{rollback.twice}
%Once you've rolled back one transaction in a repository, you can't
%roll back again in that repository until you perform another commit or
%pull.

Mercurialはトランザクションログにそのリポジトリに起こった最も新しいトラン
ザクション一回分のみを記録している．ロールバック一回毎に一つ前のリビジョ
ンに戻るわけではない．
\interaction{rollback.twice}
リポジトリ内で一度ロールバックしたら，別のコミットをするかプルをするま
でロールバックはできない．


%\section{Reverting the mistaken change}
\section{間違った変更を元に戻す}

%If you make a modification to a file, and decide that you really
%didn't want to change the file at all, and you haven't yet committed
%your changes, the \hgcmd{revert} command is the one you'll need.  It
%looks at the changeset that's the parent of the working directory, and
%restores the contents of the file to their state as of that changeset.
%(That's a long-winded way of saying that, in the normal case, it
%undoes your modifications.)

ファイルに変更を加えた後で，変更が必要でないと分かり，まだコミットされて
いない時は\hgcmd{revert}コマンドを使うことができる．このコマンドはワーキ
ングディレクトリの親チェンジセットを参照し，ファイルの内容をチェンジセッ
トの状態に戻す．（これはあなたが加えた変更をくどくどしく述べたものであ
る．）

%Let's illustrate how the \hgcmd{revert} command works with yet another
%small example.  We'll begin by modifying a file that Mercurial is
%already tracking.
%\interaction{daily.revert.modify}
%If we don't want that change, we can simply \hgcmd{revert} the file.
%\interaction{daily.revert.unmodify}
%The \hgcmd{revert} command provides us with an extra degree of safety
%by saving our modified file with a \filename{.orig} extension.
%\interaction{daily.revert.status}

\hgcmd{revert}コマンドがどのように動作するか，別の小さな例で説明する．
すでにMercurialが管理しているファイルを変更したところから始める．
\interaction{daily.revert.modify}
この変更が必要でない場合，単にファイルに\hgcmd{revert}を実行すればよい．
\interaction{daily.revert.unmodify}
\hgcmd{revert}コマンドは安全のため\filename{.orig}というファイル名で変更
をセーブする．
\interaction{daily.revert.status}

%Here is a summary of the cases that the \hgcmd{revert} command can
%deal with.  We will describe each of these in more detail in the
%section that follows.
%\begin{itemize}
%\item If you modify a file, it will restore the file to its unmodified
%  state.
%\item If you \hgcmd{add} a file, it will undo the ``added'' state of
%  the file, but leave the file itself untouched.
%\item If you delete a file without telling Mercurial, it will restore
%  the file to its unmodified contents.
%\item If you use the \hgcmd{remove} command to remove a file, it will
%  undo the ``removed'' state of the file, and restore the file to its
%  unmodified contents.
%\end{itemize}

\hgcmd{revert}コマンドが扱えるケースについてまとめる．より詳しい説明は，
後の節で行う．

\begin{itemize}
\item ファイルを変更した場合，\hgcmd{revert}はファイルを変更される前の状
      態に戻す．
\item \hgcmd{add}を実行した場合，\hgcmd{revert}はaddを取り消すが，ファイ
      ル自体はそのまま手を触れずに残す．
\item Mercurialを操作せずにファイルを消去していた場合，\hgcmd{revert}は
      ファイルを変更前の状態で復元する
\item \hgcmd{remove}コマンドでファイルを消去していた場合，変更前の状態で
      ファイルを復元する．
\end{itemize}


%\subsection{File management errors}
\subsection{ファイル管理のミス}
\label{sec:undo:mgmt}

%The \hgcmd{revert} command is useful for more than just modified
%files.  It lets you reverse the results of all of Mercurial's file
%management commands---\hgcmd{add}, \hgcmd{remove}, and so on.

\hgcmd{revert}コマンドは単に変更したファイルを戻すだけでなく，
\hgcmd{add}，\hgcmd{remove}といったMercurialのファイル操作コマンドの結果
を取り消すことができる．

%If you \hgcmd{add} a file, then decide that in fact you don't want
%Mercurial to track it, use \hgcmd{revert} to undo the add.  Don't
%worry; Mercurial will not modify the file in any way.  It will just
%``unmark'' the file.
%\interaction{daily.revert.add}

\hgcmd{add}でファイルを追加した後で，Mercurialに追跡させる必要がないと分
かった時，\hgcmd{revert}でaddを取り消すことができる．\hgcmd{revert}はファ
イルのマークを消すだけで，ファイルの中身は一切変更しないので心配する必要
はない．
\interaction{daily.revert.add}

%Similarly, if you ask Mercurial to \hgcmd{remove} a file, you can use
%\hgcmd{revert} to restore it to the contents it had as of the parent
%of the working directory.
%\interaction{daily.revert.remove}
%This works just as well for a file that you deleted by hand, without
%telling Mercurial (recall that in Mercurial terminology, this kind of
%file is called ``missing'').
%\interaction{daily.revert.missing}

同様に，\hgcmd{remove}コマンドでファイルを消去した時，\hgcmd{revert}コマ
ンドでワーキングディレクトリの親の内容にファイルを復元することができる．
\interaction{daily.revert.remove}
またMercurialを使わずに手で消したファイルについて同じ操作で復元すること
ができる．（Mercurialの用語でこれをmissingと呼んでいたことを思い出して欲
しい．）
\interaction{daily.revert.missing}

%If you revert a \hgcmd{copy}, the copied-to file remains in your
%working directory afterwards, untracked.  Since a copy doesn't affect
%the copied-from file in any way, Mercurial doesn't do anything with
%the copied-from file.
%\interaction{daily.revert.copy}

\hgcmd{copy}コマンドを取り消した場合，コピー先のファイルはワーキングディ
レクトリに残るがMercurialからは管理されない．コピー操作自体コピー元ファイ
ルに影響を与えないため，取り消しによってコピー元ファイルが影響を受けるこ
ともない．


%\subsubsection{A slightly special case: reverting a rename}
\subsubsection{やや特殊なケース：リネームの取り消し}

%If you \hgcmd{rename} a file, there is one small detail that
%you should remember.  When you \hgcmd{revert} a rename, it's not
%enough to provide the name of the renamed-to file, as you can see
%here.
%As you can see from the output of \hgcmd{status}, the renamed-to file
%is no longer identified as added, but the renamed-\emph{from} file is
%still removed!  This is counter-intuitive (at least to me), but at
%least it's easy to deal with.
%So remember, to revert a \hgcmd{rename}, you must provide \emph{both}
%the source and destination names.

\hgcmd{rename}した後では，少し留意しておくべき点がある．リネーム後に
\hgcmd{revert}した場合，ここで説明するように，リネームしたファイルの名前
を指定するだけでは不十分である．
\interaction{daily.revert.rename}
\hgcmd{status}の出力から分かるように，リネーム先のファイルはもはやaddさ
れた扱いになっていない．しかしリネーム\emph{元}のファイルはまだ消去され
たままになっている．これは（少なくとも筆者にとって）非直感的だが，取り扱
いは簡単である．
\interaction{daily.revert.rename-orig}
\hgcmd{rename}を取り消す際には，元のファイルとリネーム後のファイル
\emph{両方}を指定する必要がある．

%(By the way, if you rename a file, then modify the renamed-to file,
%then revert both components of the rename, when Mercurial restores the
%file that was removed as part of the rename, it will be unmodified.
%If you need the modifications in the renamed-to file to show up in the
%renamed-from file, don't forget to copy them over.)

（一方，リネームした後にリネーム先のファイルを編集し，リネームの前後のファ
イル名を指定して取り消しを行い，Mercurialがリネームの際に消去されたファ
イルを修復すると，このファイルは編集前の状態になっている．リネーム後のファ
イルへの変更がリネーム前のファイルに残るようにするには，コピーを作ってお
く必要がある．）

%These fiddly aspects of reverting a rename arguably constitute a small
%bug in Mercurial.

リネームを復元する時に起こる厄介ごとはおそらくMercurialのバグと言えるか
もしれない．


%\section{Dealing with committed changes}
\section{コミットされた変更の扱い}

%Consider a case where you have committed a change $a$, and another
%change $b$ on top of it; you then realise that change $a$ was
%incorrect.  Mercurial lets you ``back out'' an entire changeset
%automatically, and building blocks that let you reverse part of a
%changeset by hand.

$a$をコミットした後で別の$b$をコミットし，ここで$a$は誤りであることに気が
ついた場合を考える．Mercurialはチェンジセット全体とチェンジセットの一部分
を手でバックアウトするように促す．

%Before you read this section, here's something to keep in mind: the
%\hgcmd{backout} command undoes changes by \emph{adding} history, not
%by modifying or erasing it.  It's the right tool to use if you're
%fixing bugs, but not if you're trying to undo some change that has
%catastrophic consequences.  To deal with those, see
%section~\ref{sec:undo:aaaiiieee}.

この節を読む前に，\hgcmd{backout}コマンドは履歴に\emph{追加}することで取
り消し操作を行うことを覚えておいて欲しい．変更や消去ではない．バグの修
正のために役立つツールだが，変更の取り消しのために用いると破滅的な結果を
もたらす．後者の目的のためには\ref{sec:undo:aaaiiieee}を参照のこと．

%\subsection{Backing out a changeset}
\subsection{チェンジセットのバックアウト}

%The \hgcmd{backout} command lets you ``undo'' the effects of an entire
%changeset in an automated fashion.  Because Mercurial's history is
%immutable, this command \emph{does not} get rid of the changeset you
%want to undo.  Instead, it creates a new changeset that
%\emph{reverses} the effect of the to-be-undone changeset.

\hgcmd{backout}コマンドはチェンジセット全体の作用を打ち消す．Mercurialの
履歴は不変なので，このコマンドは取り消したいチェンジセットを取り除くもの
では\emph{ない}．その代わり，取り除きたいチェンジセットの\emph{逆}の働き
の新たなチェンジセットを生成する．

%The operation of the \hgcmd{backout} command is a little intricate, so
%let's illustrate it with some examples.  First, we'll create a
%repository with some simple changes.
%\interaction{backout.init}

\hgcmd{backout}コマンドの動作はやや複雑なので，例を挙げて説明することに
する．まずいくつかの単純な変更のあるリポジトリを考える．
\interaction{backout.init}

%The \hgcmd{backout} command takes a single changeset ID as its
%argument; this is the changeset to back out.  Normally,
%\hgcmd{backout} will drop you into a text editor to write a commit
%message, so you can record why you're backing the change out.  In this
%example, we provide a commit message on the command line using the
%\hgopt{backout}{-m} option.

\hgcmd{backout}コマンドはバックアウトすべきチェンジセットのIDを一つ引数に
取る．\hgcmd{backout}はデフォルトでコミットメッセージ入力のためにテキスト
エディタを起動するので．バックアウトの理由を記録しておく．この例では
\hgopt{backout}{-m}オプションを使ってコミットメッセージを記録している．


%\subsection{Backing out the tip changeset}
\subsection{tipチェンジセットをバックアウトする}

%We're going to start by backing out the last changeset we committed.
%\interaction{backout.simple}
%You can see that the second line from \filename{myfile} is no longer
%present.  Taking a look at the output of \hgcmd{log} gives us an idea
%of what the \hgcmd{backout} command has done.
%\interaction{backout.simple.log}
%Notice that the new changeset that \hgcmd{backout} has created is a
%child of the changeset we backed out.  It's easier to see this in
%figure~\ref{fig:undo:backout}, which presents a graphical view of the
%change history.  As you can see, the history is nice and linear.

最後にコミットしたチェンジセットをバックアウトすることから始める．
\interaction{backout.simple}
\filename{myfile}の2行目がなくなっているのが分かると思う．\hgcmd{log}を
見てみると，\hgcmd{backout}が何をしたのかが分かる．
\interaction{backout.simple.log}
\hgcmd{backout}が生成した新しいチェンジセットは，バックアウトしたチェン
ジセットの子になっている．\ref{fig:undo:backout}は更新履歴を図示したもの
で，理解の助けになるはずだ．図から分かるように履歴は線形で整合が取れている．

\begin{figure}[htb]
  \centering
  \grafix{undo-simple}
%  \caption{Backing out a change using the \hgcmd{backout} command}
  \caption{\hgcmd{backout}コマンドを使って更新をバックアウト}
  \label{fig:undo:backout}
\end{figure}

%\subsection{Backing out a non-tip change}
\subsection{tipでない変更をバックアウトする}

%If you want to back out a change other than the last one you
%committed, pass the \hgopt{backout}{--merge} option to the
%\hgcmd{backout} command.
%\interaction{backout.non-tip.clone}
%This makes backing out any changeset a ``one-shot'' operation that's
%usually simple and fast.
%\interaction{backout.non-tip.backout}

最後のコミット以外の変更をバックアウトしたい時は，
\hgcmd{backout}に\hgopt{backout}{--merge}オプションを付ける．
\interaction{backout.non-tip.clone}
このオプションはどんなチェンジセットでも一回の動作で行うことができ，手
早く簡単である．
\interaction{backout.non-tip.backout}

%If you take a look at the contents of \filename{myfile} after the
%backout finishes, you'll see that the first and third changes are
%present, but not the second.
%\interaction{backout.non-tip.cat}

バックアウトが終ったあとで\filename{myfile}の中身を見ると，1番目と3番目
の変更だけが残っており，2番目の変更が消えていることがわかる．
\interaction{backout.non-tip.cat}

%As the graphical history in figure~\ref{fig:undo:backout-non-tip}
%illustrates, Mercurial actually commits \emph{two} changes in this
%kind of situation (the box-shaped nodes are the ones that Mercurial
%commits automatically).  Before Mercurial begins the backout process,
%it first remembers what the current parent of the working directory
%is.  It then backs out the target changeset, and commits that as a
%changeset.  Finally, it merges back to the previous parent of the
%working directory, and commits the result of the merge.

図\ref{fig:undo:backout-non-tip}で示された履歴で，Mercurialは2つのコミッ
トを行っている．（図中で箱で示された節点はMercurialが自動的にコミットし
た変更である．）バックアウトプロセスの前にMercurialは，現在のワーキングディ
レクトリの親が何であるかを記憶する．そしてターゲットのチェンジセットを取
り除き，これをチェンジセットとしてコミットする．最後にワーキングディレク
トリの前の親へマージを行い，マージの結果をコミットする．

\begin{figure}[htb]
  \centering
  \grafix{undo-non-tip}
%  \caption{Automated backout of a non-tip change using the
 %  \hgcmd{backout} command}
  \caption{tipでない変更を\hgcmd{backout}コマンドで自動的にバックアウトする}
  \label{fig:undo:backout-non-tip}
\end{figure}

%The result is that you end up ``back where you were'', only with some
%extra history that undoes the effect of the changeset you wanted to
%back out.

最終的に，いくらかの余計な履歴を残しつつ，取り除きたかったチェンジセット
の影響を除去して，望む状態に戻すことができている．


%\subsubsection{Always use the \hgopt{backout}{--merge} option}
\subsubsection{常に\hgopt{backout}{--merge}オプションを使う}

%In fact, since the \hgopt{backout}{--merge} option will do the ``right
%thing'' whether or not the changeset you're backing out is the tip
%(i.e.~it won't try to merge if it's backing out the tip, since there's
%no need), you should \emph{always} use this option when you run the
%\hgcmd{backout} command.

バックアウトしようとするチェンジセットがチップかチップでないかにか変わら
ず，\hgcmd{backout}コマンドを使おうとする時は\emph{常に}
\hgopt{backout}{--merge}オプションを使うべきである．対象がチップである場
合は不要なマージを試みることはないため，常にこのオプションを指定して問題
ない．


%\subsection{Gaining more control of the backout process}
\subsection{バックアウトプロセスをより細かく制御する}

%While I've recommended that you always use the
%\hgopt{backout}{--merge} option when backing out a change, the
%\hgcmd{backout} command lets you decide how to merge a backout
%changeset.  Taking control of the backout process by hand is something
%you will rarely need to do, but it can be useful to understand what
%the \hgcmd{backout} command is doing for you automatically. To
%illustrate this, let's clone our first repository, but omit the
%backout change that it contains.

変更をバックアウトする際，常に\hgopt{backout}{--merge}オプションを使うこ
とを勧めたが，\hgcmd{backout}コマンドでは，バックアウトするチェンジセット
をどのようにマージするか指定することができる．バックアウトプロセスを手で
コントロールする必要はほとんどないはずだが，\hgcmd{backout}コマンドが自動
でどのように動作しているのか理解するのには役立つかも知れない．動作を説明
するために最初のリポジトリのクローンを，バックアウトを除いて作って始める
ことにしよう．

%\interaction{backout.manual.clone}
%As with our earlier example, We'll commit a third changeset, then back
%out its parent, and see what happens.
%\interaction{backout.manual.backout} 
%Our new changeset is again a descendant of the changeset we backout
%out; it's thus a new head, \emph{not} a descendant of the changeset
%that was the tip.  The \hgcmd{backout} command was quite explicit in
%telling us this.
%\interaction{backout.manual.log}
%
%\interaction{backout.manual.clone}

前に使った例のように，3番目のチェンジセットをコミットした後で，その親を
バックアウトして何が起きるか見てみよう．
\interaction{backout.manual.backout} 

前の例と同様に，新しいチェンジセットはバックアウトしたチェンジセットの子
にあたる．したがって新しいヘッドはチップの子では\emph{ない}．
\hgcmd{backout}コマンドはこの親子関係についてかなりはっきりと表示する．
\interaction{backout.manual.log}

\interaction{backout.manual.clone}

%Again, it's easier to see what has happened by looking at a graph of
%the revision history, in figure~\ref{fig:undo:backout-manual}.This
%makes it clear that when we use \hgcmd{backout} to back out a change
%other than the tip, Mercurial adds a new head to the repository (the
%change it committed is box-shaped).

ここでもリビジョン履歴のグラフ\ref{fig:undo:backout-manual}を見れば，何が
起きているのか理解しやすい．チップ以外の変更をバックアウトするために
\hgcmd{backout}を使った時，Mercurialが新しいヘッドをリポジトリに追加する
のがわかる．（四角で示されたコミット．）

\begin{figure}[htb]
  \centering
  \grafix{undo-manual}
%  \caption{Backing out a change using the \hgcmd{backout} command}
  \caption{\hgcmd{backout}コマンドによる変更のバックアウト}
  \label{fig:undo:backout-manual}
\end{figure}

%After the \hgcmd{backout} command has completed, it leaves the new
%``backout'' changeset as the parent of the working directory.
%\interaction{backout.manual.parents}
%Now we have two isolated sets of changes.
%\interaction{backout.manual.heads}

\hgcmd{backout}コマンドは，完了した後，バックアウトチェンジセットをワーキ
ングディレクトリの親として残す．
\interaction{backout.manual.parents}
ここで2つの隔離された変更のセットが存在することになる．
\interaction{backout.manual.heads}


%Let's think about what we expect to see as the contents of
%\filename{myfile} now.  The first change should be present, because
%we've never backed it out.  The second change should be missing, as
%that's the change we backed out.  Since the history graph shows the
%third change as a separate head, we \emph{don't} expect to see the
%third change present in \filename{myfile}.
%\interaction{backout.manual.cat}
%To get the third change back into the file, we just do a normal merge
%of our two heads.
%\interaction{backout.manual.merge}
%Afterwards, the graphical history of our repository looks like
%figure~\ref{fig:undo:backout-manual-merge}.

今ここで\filename{myfile}の内容を見たいとする．最初の変更はバックアウトし
ていないので存在しているはずである．2番目の変更はバックアウトしたので消
えて無くなっているはずだ．3番目の変更は履歴グラフで分離したヘッドとして
表示されるため，3番目の変更が\filename{myfile}にあるとは期待していない．
\interaction{backout.manual.cat}
3番目の変更をファイルに反映させるためには，2つのヘッドをマージしてやれば
よい．
\interaction{backout.manual.merge}
その後ではリポジトリの履歴のグラフは図
\ref{fig:undo:backout-manual-merge}のようになる

\begin{figure}[htb]
  \centering
  \grafix{undo-manual-merge}
%  \caption{Manually merging a backout change}
  \caption{バックアウトチェンジの手動によるマージ}
  \label{fig:undo:backout-manual-merge}
\end{figure}

%\subsection{Why \hgcmd{backout} works as it does}
\subsection{なぜ\hgcmd{backout}はこのように動作するのか}

%Here's a brief description of how the \hgcmd{backout} command works.
%\begin{enumerate}
%\item It ensures that the working directory is ``clean'', i.e.~that
%  the output of \hgcmd{status} would be empty.
%\item It remembers the current parent of the working directory.  Let's
%  call this changeset \texttt{orig}
%\item It does the equivalent of a \hgcmd{update} to sync the working
%  directory to the changeset you want to back out.  Let's call this
%  changeset \texttt{backout}
%\item It finds the parent of that changeset.  Let's call that
%  changeset \texttt{parent}.
%\item For each file that the \texttt{backout} changeset affected, it
%  does the equivalent of a \hgcmdargs{revert}{-r parent} on that file,
%  to restore it to the contents it had before that changeset was
%  committed.
%\item It commits the result as a new changeset.  This changeset has
%  \texttt{backout} as its parent.
%\item If you specify \hgopt{backout}{--merge} on the command line, it
%  merges with \texttt{orig}, and commits the result of the merge.
%\end{enumerate}

\hgcmd{backout}がどのように動作するか完結に説明すると以下のようになる．
\begin{enumerate}
 \item ワーキングディレクトリがクリーンであることを確認する．i.e.\hgcmd{status}
      が空であることを確認する
 \item 現在のワーキングディレクトリの親を記憶する．このチェンジセットを
       \texttt{orig}と呼ぶことにする．
 \item ワーキングディレクトリを，バックアウトしたチェンジセットの内容に
       するために\hgcmd{update}と等価な動作を行う．このチェンジセット
       を\texttt{backout}と呼ぶ．
 \item そのチェンジセットの親を見つけ出す．このチェンジセットを
       \texttt{parent}と呼ぶことにする．
 \item \texttt{backout}チェンジセットが影響する各々のファイルに対して，
       \hgcmdargs{revert}{-r parent}と等価な操作を行い，チェンジセットが
       コミットされる前の状態に戻す．
 \item 新しいチェンジセットの結果をコミットする．このチェンジセットは
       \texttt{backout}を親に持つ．
 \item \hgopt{backout}{--merge}をコマンドラインから入力した場合，
       \texttt{orig}とのマージを行い，結果をコミットする．
\end{enumerate}

%An alternative way to implement the \hgcmd{backout} command would be
%to \hgcmd{export} the to-be-backed-out changeset as a diff, then use
%the \cmdopt{patch}{--reverse} option to the \command{patch} command to
%reverse the effect of the change without fiddling with the working
%directory.  This sounds much simpler, but it would not work nearly as
%well.

\hgcmd{backout}コマンドを実装する別の方法として，\hgcmd{export}でバックア
ウトされるべきチェンジセットを差分として出力し，
\command{patch}を\cmdopt{patch}{--reverse}オプション付きで呼び，ワーキン
グディレクトリの操作を省略してリバースパッチする方法が考えられる．
この方法はずっと単純だが，ほとんどうまく動かない．

%The reason that \hgcmd{backout} does an update, a commit, a merge, and
%another commit is to give the merge machinery the best chance to do a
%good job when dealing with all the changes \emph{between} the change
%you're backing out and the current tip.  

\hgcmd{backout}がアップデート，コミット，マージ，コミットを行う理由は，
バックアウトすべき変更と現在のチップの間で，マージ機構が最も良い結果を得
られるようにするためである．

%If you're backing out a changeset that's~100 revisions back in your
%project's history, the chances that the \command{patch} command will
%be able to apply a reverse diff cleanly are not good,because
%intervening changes are likely to have ``broken the context'' that
%\command{patch} uses to determine whether it can apply a patch (if
%this sounds like gibberish, see \ref{sec:mq:patch} for a
%discussion of the \command{patch} command).
%Also, Mercurial's merge machinery will handle files and directories
%being renamed, permission changes, and modifications to binary files,
%none of which \command{patch} can deal with.

もしプロジェクトの履歴の中で100リビジョンも遡るようなチェンジセットをバッ
クアウトするとすれば，\command{patch}がdiffを適用できる可能性は明らかに低
い．間にある変更が，\command{patch}コマンドがパッチ適用の可否を判断するた
めの文脈を壊している可能性が高いからである．（この話が分からない場合は
\ref{sec:mq:patch}の\command{patch}コマンドに関する議論を参照して欲しい．）
また，Mercurialのマージ機構は，\command{patch}コマンドが扱えないファイル
とディレクトリのリネーム，パーミッション変更，バイナリファイルへの変更な
どを扱うことができる．


%\section{Changes that should never have been}
\section{存在すべきでない変更}
\label{sec:undo:aaaiiieee}

%Most of the time, the \hgcmd{backout} command is exactly what you need
%if you want to undo the effects of a change.  It leaves a permanent
%record of exactly what you did, both when committing the original
%changeset and when you cleaned up after it.

大抵の場合，\hgcmd{backout}はある変更を取り消そうとする際に思ったように機
能するはずである．元々のコミットやそれを取り除いた時に何をしたのか永続的
な記憶が残される．

%On rare occasions, though, you may find that you've committed a change
%that really should not be present in the repository at all.  For
%example, it would be very unusual, and usually considered a mistake,
%to commit a software project's object files as well as its source
%files.Object files have almost no intrinsic value, and they're
%\emph{big}, so they increase the size of the repository and the amount
%of time it takes to clone or pull changes.

それでもたまにリポジトリに全く残したくない変更をコミットしてしまうことが
ある．たとえば，非常に変なコミットや，通常ミスと考えられるようなコミット，
ソースだけではなくプロジェクトのオブジェクトファイルもコミットしてしまう
などが有り得る．オブジェクトファイルは固有の値を持ち得ず，かつ\emph{大き
い}．そのため，リポジトリのサイズを増やし，クローンやプルに余計な時間が掛
かるようになる．

%Before I discuss the options that you have if you commit a ``brown
%paper bag'' change (the kind that's so bad that you want to pull a
%brown paper bag over your head), let me first discuss some approaches
%that probably won't work.

茶色の紙袋コミット（茶色の紙袋を頭に被りたいぐらいバツの悪いコミット）に
使えるオプションについて議論する前に，いくつかのうまく行かないアプローチ
を述べたい．

%Since Mercurial treats history as accumulative---every change builds
%on top of all changes that preceded it---you generally can't just make
%disastrous changes disappear.  The one exception is when you've just
%committed a change, and it hasn't been pushed or pulled into another
%repository.  That's when you can safely use the \hgcmd{rollback}
%command, as I detailed in section~\ref{sec:undo:rollback}.

Mercurialは履歴を累積的なものとして扱う．全ての変更はそれに先立つ全ての変
更の上になりたっている．一般的に言って破壊的な変更を回避することはできな
い．たった一つの例外はコミットを行った直後で，他のリポジトリにプッシュ
もプルもされていない場合である．その場合，\ref{sec:undo:rollback}のセクショ
ンで詳しく触れたように，安全に\hgcmd{rollback}を実行することができる．

%After you've pushed a bad change to another repository, you \emph{could}
%still use \hgcmd{rollback} to make your local copy of the change
%disappear, but it won't have the consequences you want.  The change will
%still be present in the remote repository, so it will reappear in your
%local repository the next time you pull.

間違った変更を他のリポジトリにプッシュした後でもローカルコピーの変更を取
り消すために依然として\hgcmd{rollback}を使うことが\emph{できる}が，これは
意図したような結果にはならない．変更は依然としてリモートのリポジトリには
存在しており，次にプルした時にはローカルリポジトリにも現れる．

%If a situation like this arises, and you know which repositories your
%bad change has propagated into, you can \emph{try} to get rid of the
%changee from \emph{every} one of those repositories.  This is, of
%course, not a satisfactory solution: if you miss even a single
%repository while you're expunging, the change is still ``in the
%wild'', and could propagate further.

このような状況になった時，もしどのリポジトリにこの間違った変更が波及して
いるのかが明らかであれば，それらのリポジトリの一つ一つから，変更を取り除
くことを試みることができる．これはもちろん満足のいく解決法ではない．もし
一つでも消去を忘れれば，変更は野放しになっており，さらに広がりうる．

%If you've committed one or more changes \emph{after} the change that
%you'd like to see disappear, your options are further reduced.
%Mercurial doesn't provide a way to ``punch a hole'' in history,
%leaving changesets intact.

もし1つ以上の新たな変更を，消したいと思っている変更の後にコミットしてい
たとすれば，使えるオプションはさらに少なくなる．Mercurialはチェンジセッ
トをそのままに履歴に穴を開けるような方法を提供していない．

%XXX This needs filling out.  The \texttt{hg-replay} script in the
%\texttt{examples} directory works, but doesn't handle merge
%changesets.  Kind of an important omission.

XXX 追記の必要性あり．\texttt{examples}ディレクトリ内の
\texttt{hg-replay}スクリプトは機能するが，チェンジセットのマージを扱わな
い．重要な制限である．


%\subsection{Protect yourself from ``escaped'' changes}
\subsection{逸脱した変更から自分自身を守る}

%If you've committed some changes to your local repository and they've
%been pushed or pulled somewhere else, this isn't necessarily a
%disaster.  You can protect yourself ahead of time against some classes
%of bad changeset.  This is particularly easy if your team usually
%pulls changes from a central repository.

ローカルリポジトリにいくつかの変更をコミットし，それらが別の所にプッシュ
またはプルされていて，必ずしも大災害とは言えない．あなたはいくつかのクラ
スの間違った変更から自分自身で身を守ることができる．これはあなたのチーム
が中央のリポジトリから変更をプルしている場合は特に簡単である．

%By configuring some hooks on that repository to validate incoming
%changesets (see chapter~\ref{chap:hook}), you can automatically
%prevent some kinds of bad changeset from being pushed to the central
%repository at all.  With such a configuration in place, some kinds of
%bad changeset will naturally tend to ``die out'' because they can't
%propagate into the central repository.
%Better yet, this happens without any need for explicit intervention.

中央リポジトリの上で，変更到着にフックを設定する（\ref{chap:hook}を参照）
ことで，ある種の誤ったチェンジセットが中央リポジトリにコミットされるのを
自動的に防ぐことができる．そのような設定を行うことで，ある種の誤ったチェ
ンジセットは中央リポジトリに波及することができず，死滅していく傾向があ
る．好都合なことに，死滅は陽に介入する必要なく起きる。

%For instance, an incoming change hook that verifies that a changeset
%will actually compile can prevent people from inadvertantly ``breaking
%the build''.

例えば，チェンジセットを実際にコンパイルする変更到着フックは，不注意によ
るビルド不能を防ぐことができる．

%\section{Finding the source of a bug}
\section{バグの原因を見つける}
\label{sec:undo:bisect}

%While it's all very well to be able to back out a changeset that
%introduced a bug, this requires that you know which changeset to back
%out.  Mercurial provides an invaluable command, called
%\hgcmd{bisect}, that helps you to automate this process and accomplish
%it very efficiently.

バグを発生させたチェンジセットをバックアウトするためには，どのチェンジセッ
トでバグの混入が起きたのかを知らねばならない．Mercurialは\hgcmd{bisect}
という有用なコマンドを提供しており，これによってチェンジセットの特定を自
動化し，バックアウトを極めて効果的に行うことができる．

%The idea behind the \hgcmd{bisect} command is that a changeset has
%introduced some change of behaviour that you can identify with a
%simple binary test.  You don't know which piece of code introduced the
%change, but you know how to test for the presence of the bug.  The
%\hgcmd{bisect} command uses your test to direct its search for the
%changeset that introduced the code that caused the bug.

\hgcmd{bisect}コマンドの背後には，チェンジセットによって単純なバイナリテ
ストで十分識別可能な挙動の変化が生れるという考え方がある．あなたはどのコー
ドが変化を引き起こしたのかはわからないが，バグが起きているかをテストする
方法は知っている．\hgcmd{bisect}コマンドは，テストによってバグを引き起こ
したチェンジセットを特定する．

%Here are a few scenarios to help you understand how you might apply
%this command.
%\begin{itemize}
%\item The most recent version of your software has a bug that you
%  remember wasn't present a few weeks ago, but you don't know when it
%  was introduced.  Here, your binary test checks for the presence of
%  that bug.
%\item You fixed a bug in a rush, and now it's time to close the entry
%  in your team's bug database.  The bug database requires a changeset
%  ID when you close an entry, but you don't remember which changeset
%  you fixed the bug in.  Once again, your binary test checks for the
%  presence of the bug.
%\item Your software works correctly, but runs~15\% slower than the
%  last time you measured it.  You want to know which changeset
%  introduced the performance regression.  In this case, your binary
%  test measures the performance of your software, to see whether it's
%  ``fast'' or ``slow''.
%\item The sizes of the components of your project that you ship
%  exploded recently, and you suspect that something changed in the way
%  you build your project.
%%\end{itemize}

以下はこのコマンドをどのように適用できるのか理解を助けるシナリオである．
\begin{itemize}
 \item バグが起きていなかった最も新しいバージョンを覚えているが，どのバー
       ジョンでバグが混入したか分からない．ここでバイナリテストを行い，
       バグの存在を調べる．
 \item バグを大急ぎで修正し，あなたのチームのバグデータベースをクローズ
       する．バグデータベースはどこでバグが修正されたかのチェンジセット
       のIDを必要とするが，あなたはどのチェンジセットで修正されたか記憶
       していない．ここでまたバグの存在をバイナリテストする．
 \item あなたのソフトウェアは正しく動いたが，以前測定した時よりも15\%遅
       くなっていた．あなたはどのチェンジセットがこの性能劣化をもたらし
       たのか知りたい．この場合，バイナリテストで速度を測定する．
 \item 出荷するプロジェクトのコンポーネントサイズが最近爆発的に増えた．
       あなたはプロジェクトのビルドの方法になんらかの変化が起きたのでは
       ないかと疑っている．
\end{itemize}

%From these examples, it should be clear that the \hgcmd{bisect}
%command is not useful only for finding the sources of bugs.  You can
%use it to find any ``emergent property'' of a repository (anything
%that you can't find from a simple text search of the files in the
%tree) for which you can write a binary test.

この例から，\hgcmd{bisect}コマンドは単にバグの所在を探すのに役立つだけで
はなく、バイナリテストを用意できるのであれば、リポジトリで起きたあらゆる
変化（単にツリーをテキストサーチしたのでは発見できない変化）を知るのに使
えることがわかる。

%We'll introduce a little bit of terminology here, just to make it
%clear which parts of the search process are your responsibility, and
%which are Mercurial's.  A \emph{test} is something that \emph{you} run
%when \hgcmd{bisect} chooses a changeset. A \emph{probe} is what
%\hgcmd{bisect} runs to tell whether a revision is good.  Finally,
%we'll use the word ``bisect'', as both a noun and a verb, to stand in
%for the phrase ``search using the \hgcmd{bisect} command''.

ここでサーチのどのパートがあなたの責任に属し，どのパートがMercurialに属す
るのか明確にするために少しばかり用語を導入する．\emph{test}は\emph{あな
た}が\hgcmd{bisect}を実行する時に選んだチェンジセットである．
\emph{probe}は\hgcmd{bisect}がリビジョンが良いか判定するリビジョンである．
``bisect''という単語を``\hgcmd{bisect}コマンドを使ってサーチする''という
ことの同義語として名詞と動詞両方で用いる．

%One simple way to automate the searching process would be simply to
%probe every changeset.  However, this scales poorly.If it took ten
%minutes to test a single changeset, and you had 10,000 changesets in
%your repository, the exhaustive approach would take on average~35
%\emph{days} to find the changeset that introduced a bug. Even if you
%knew that the bug was introduced by one of the last 500 changesets,
%and limited your search to those, you'd still be looking at over 40
%hours to find the changeset that introduced your bug.

サーチプロセスを自動化する単純な方法は，全てのチェンジセットをprobeするこ
とである．しかしこれは殆んどスケールしない．一つのチェンジセットのチェッ
クに10分かかり，リポジトリにチェンジセットが10000あったとしたら，虱潰しの
アプローチはバグを発生させたチェンジセットの特定に平均で35日かかる．バグ
が最後の500チェンジセットで発生したことが分かっていて，サーチをそれらのチェ
ンジセットに限定したとしても，バグを引き起こしたチェンジセットの特定に40
時間以上かかる．

%What the \hgcmd{bisect} command does is use its knowledge of the
%``shape'' of your project's revision history to perform a search in
%time proportional to the \emph{logarithm} of the number of changesets
%to check (the kind of search it performs is called a dichotomic
%search).

%With this approach, searching through 10,000 changesets will
%take less than three hours, even at ten minutes per test (the search
%will require about 14 tests).  Limit your search to the last hundred
%changesets, and it will take only about an hour (roughly seven tests).

\hgcmd{bisect}はあなたのプロジェクトのリビジョン履歴の``シェイプ''の知識
を，サーチすべきチェンジセット数の\emph{対数}に比例した時間でサーチするた
めに使う．（二分探索を行う．）このアプローチによって10000チェンジセット
のサーチは，各々のサーチが10分かかったとしても，テスト数は14で3時間以下で
終了する．最後の100のチェンジセットに限って行ったとすると，およそ7回の
テストで1時間程度で終了する．

%The \hgcmd{bisect} command is aware of the ``branchy'' nature of a
%Mercurial project's revision history, so it has no problems dealing
%with branches, merges, or multiple heads in a repoository.  It can
%prune entire branches of history with a single probe, which is how it
%operates so efficiently.

\hgcmd{bisect}コマンドは，Mercurialプロジェクトのリビジョン履歴が枝分かれ
しがちな性質を持つことを念頭において設計されており，リポジトリにブランチ，
マージ，複数のヘッドがあっても問題なく取り扱える．一回のprobeで履歴の中
のある分枝全てを刈ることができるため，極めて効率的に動作する．

%\subsection{Using the \hgcmd{bisect} command}
\subsection{\hgcmd{bisect}コマンドを使う}

%Here's an example of \hgcmd{bisect} in action.
\hgcmd{bisect}の動作を例で示す．

%\begin{note}
%  In versions 0.9.5 and earlier of Mercurial, \hgcmd{bisect} was not a
%  core command: it was distributed with Mercurial as an extension.
%  This section describes the built-in command, not the old extension.
%\end{note}

\begin{note}
  バージョン0.9.5以前のMercurialでは，\hgcmd{bisect}はコアコマンドではな
 く，extensionとしてMercurialに同梱されていた．この節は古いextensionにつ
 いてではなく，ビルトインコマンドとしての\hgcmd{bisect}について述べている．
\end{note}

%Now let's create a repository, so that we can try out the
%\hgcmd{bisect} command in isolation.
%\interaction{bisect.init}
%We'll simulate a project that has a bug in it in a simple-minded way:
%create trivial changes in a loop, and nominate one specific change
%that will have the ``bug''.  This loop creates 35 changesets, each
%adding a single file to the repository.  We'll represent our ``bug''
%with a file that contains the text ``i have a gub''.
%\interaction{bisect.commits}

独立して\hgcmd{bisect}を試せるようにリポジトリを作成する．
\interaction{bisect.init}
単純なバグのあるプロジェクトをシミュレートする．バグは繰返し操作の間に自
明な変更を行い，特定の1つの変更をバグを持つと指名する．このループは35
のチェンジセットを作り，各々，1つのファイルをリポジトリに追加する．バグ
は``i have a gub''という文字列を持つファイルで表現する．
\interaction{bisect.commits}

%The next thing that we'd like to do is figure out how to use the
%\hgcmd{bisect} command.  We can use Mercurial's normal built-in help
%mechanism for this.
%\interaction{bisect.help}

次に\hgcmd{bisect}の使い方を説明したい．Mercurialのビルトインのヘルプが
使える．
\interaction{bisect.help}

%The \hgcmd{bisect} command works in steps.  Each step proceeds as follows.
%\begin{enumerate}
%\item You run your binary test.
%  \begin{itemize}
%  \item If the test succeeded, you tell \hgcmd{bisect} by running the
%    \hgcmdargs{bisect}{good} command.
%  \item If it failed, run the \hgcmdargs{bisect}{--bad} command.
%  \end{itemize}
%\item The command uses your information to decide which changeset to
%  test next.
%\item It updates the working directory to that changeset, and the
%  process begins again.
%\end{enumerate}
%The process ends when \hgcmd{bisect} identifies a unique changeset
%that marks the point where your test transitioned from ``succeeding''
%to ``failing''.

\hgcmd{bisect}コマンドは段階を踏んで動作する．各段階は以下のように進む．
\begin{enumerate}
\item バイナリテストを実行する
  \begin{itemize}
   \item テストが成功した場合，\hgcmd{bisect}を引数\hgcmdargs{bisect}{good}
	を付けて実行する．
   \item テストが失敗した場合は\hgcmdargs{bisect}{--bad}コマンドを実行す
	 る．
  \end{itemize}
 \item コマンドは引数で渡された情報を使って次にどのチェンジセットをテス
      トすべきか決定する．
 \item コマンドはワーキングディレクトリをそのチェンジセットに更新する．
      プロセスを再開する．
\end{enumerate}
\hgcmd{bisect}のプロセスは，テストが成功から失敗へ変化したチェンジセット
を特定できると終了する．

%To start the search, we must run the \hgcmdargs{bisect}{--reset} command.
%\interaction{bisect.search.init}

サーチを始めるには\hgcmdargs{bisect}{--reset}を実行する．
\interaction{bisect.search.init}

%In our case, the binary test we use is simple: we check to see if any
%file in the repository contains the string ``i have a gub''.  If it
%does, this changeset contains the change that ``caused the bug''.  By
%convention, a changeset that has the property we're searching for is
%``bad'', while one that doesn't is ``good''.

このケースでは，バイナリテストは単純で，リポジトリ内に``i have a gub''を
含むファイルがあるかどうかをチェックするだけである．もしこれがあれば，そ
のチェンジセットがバグを引き起こしている変更を含んでいるということになる．
慣例に従って，探しているチェンジセットを``bad''，それ以外を``good''と呼
ぶことにする．

%Most of the time, the revision to which the working directory is
%synced (usually the tip) already exhibits the problem introduced by
%the buggy change, so we'll mark it as ``bad''.
%\interaction{bisect.search.bad-init}

大抵の場合，ワーキングディレクトリが同期しているリビジョン（通常はtipの
はずだ）は，バグのある変更によって引き起こされた問題を示しているので，こ
のリビジョンを``bad''とマークする．
\interaction{bisect.search.bad-init}

%Our next task is to nominate a changeset that we know \emph{doesn't}
%have the bug; the \hgcmd{bisect} command will ``bracket'' its search
%between the first pair of good and bad changesets.  In our case, we
%know that revision~10 didn't have the bug.  (I'll have more words
%about choosing the first ``good'' changeset later.)
%\interaction{bisect.search.good-init}

次にバグを\emph{含まない}リビジョンを指名する．\hgcmd{bisect}コマンドは
最初の``good''チェンジセットと``bad''チェンジセットをブラケットする．こ
の例では，リビジョン~10はバグを持たないと分かっている．（最初の``good''
チェンジセットの選び方については後述する．）
\interaction{bisect.search.good-init}

%Notice that this command printed some output.
%\begin{itemize}
%\item It told us how many changesets it must consider before it can
%  identify the one that introduced the bug, and how many tests that
%  will require.
%\item It updated the working directory to the next changeset to test,
%  and told us which changeset it's testing.
%\end{itemize}

コマンドから出力があることに注意．
\begin{itemize}
 \item バグの入ったチェンジセットを特定するまでに考慮すべきチェンジセット
      の個数と，必要な検査の回数を表示する．
 \item ワーキングディレクトリを次のテストすべきチェンジセットに更新し，
       どのチェンジセットをテストしているのかを表示する．
\end{itemize}

%We now run our test in the working directory.  We use the
%\command{grep} command to see if our ``bad'' file is present in the
%working directory.  If it is, this revision is bad; if not, this
%revision is good.
%\interaction{bisect.search.step1}

ここでワーキングディレクトリでテストを行うことができる．\command{grep}コ
マンドを使って``bad''ファイルがワーキングディレクトリにあるかどうかをチェッ
クする．もし存在すれば，リビジョンはbadで，存在しなければリビジョンは
goodということになる．
\interaction{bisect.search.step1}

%This test looks like a perfect candidate for automation, so let's turn
%it into a shell function.
%\interaction{bisect.search.mytest}
%We can now run an entire test step with a single command,
%\texttt{mytest}.
%\interaction{bisect.search.step2}
%A few more invocations of our canned test step command, and we're
%done.
%\interaction{bisect.search.rest}

このテストは完全に自動化できる．シェル関数にしてみよう．
\interaction{bisect.search.mytest}
テスト全体を一つの\texttt{mytest}コマンドとして実行できるようになった．
\interaction{bisect.search.step2}
このパックされたテストコマンドを起動するだけでテストが完了する．
\interaction{bisect.search.rest}

%Even though we had~40 changesets to search through, the \hgcmd{bisect}
%command let us find the changeset that introduced our ``bug'' with
%only five tests.  Because the number of tests that the \hgcmd{bisect}
%command grows logarithmically with the number of changesets to
%search, the advantage that it has over the ``brute force'' search
%approach increases with every changeset you add.

40個のチェンジセットがあるにもかかわらず，\hgcmd{bisect}コマンドはバグを
もたらしたチェンジセットを5回のテストで発見することができた．
\hgcmd{bisect}のテスト回数は探索すべきチェンジセット数が増えるに従って，
対数的に増えるが，虱潰し探索に対する優位性は，チェンジセットが増加するに
従って増加する．


%\subsection{Cleaning up after your search}
\subsection{サーチ後のクリーンアップ}

%When you're finished using the \hgcmd{bisect} command in a
%repository, you can use the \hgcmdargs{bisect}{reset} command to drop
%the information it was using to drive your search.  The command
%doesn't use much space, so it doesn't matter if you forget to run this
%command.  However, \hgcmd{bisect} won't let you start a new search in
%that repository until you do a \hgcmdargs{bisect}{reset}.
%\interaction{bisect.search.reset}

リポジトリ内で\hgcmd{bisect}コマンドを使い終った後に
\hgcmdargs{bisect}{reset}コマンドで探索に使った情報を消去することができ
る．コマンドは大きなスペースを使うわけではないので，このコマンドを実行す
るのを忘れても特に問題はない．しかし\hgcmd{bisect}は
\hgcmdargs{bisect}{reset}が実行されるまで，そのリポジトリ内で新たな探索
を始めることはできない．
\interaction{bisect.search.reset}

%\section{Tips for finding bugs effectively}
\section{効率的なバグの発見法}

%\subsection{Give consistent input}
\subsection{正しい入力を行う}

%The \hgcmd{bisect} command requires that you correctly report the
%result of every test you perform.  If you tell it that a test failed
%when it really succeeded, it \emph{might} be able to detect the
%inconsistency.  If it can identify an inconsistency in your reports,
%it will tell you that a particular changeset is both good and bad.
%However, it can't do this perfectly; it's about as likely to report
%the wrong changeset as the source of the bug.

\hgcmd{bisect}コマンドは各テストで正しく結果を入力することが必要である．
もしテストに成功したのに失敗と入力すれば，矛盾が生じうる．入力の中に矛盾
があることが分かれば，コマンドは特定のチェンジセットをgoodかつbadと表示す
る．しかし矛盾を完璧に見つけ出すことは困難で，誤ったチェンジセットをバグ
の起源と報告する可能性が高い．

%\subsection{Automate as much as possible}
\subsection{できる限り自動化する}

%When I started using the \hgcmd{bisect} command, I tried a few times
%to run my tests by hand, on the command line.  This is an approach
%that I, at least, am not suited to.  After a few tries, I found that I
%was making enough mistakes that I was having to restart my searches
%several times before finally getting correct results.

\hgcmd{bisect}コマンドを使いはじめた時，数回，コマンドラインから手でテス
トを実行した．この方法は適した方法ではない．数回のテストの後で，最終的な
結果を得るためにサーチをやりなおさなければならないことに気づくことが何度
かあった．

%My initial problems with driving the \hgcmd{bisect} command by hand
%occurred even with simple searches on small repositories; if the
%problem you're looking for is more subtle, or the number of tests that
%\hgcmd{bisect} must perform increases, the likelihood of operator
%error ruining the search is much higher.  Once I started automating my
%tests, I had much better results.

\hgcmd{bisect}コマンドを手で実行していた時の最初の問題は，小さなリポジト
リでの単純なサーチでも起こった．もし問題がもっと劣悪で，\hgcmd{bisect}が
実行しなければならないテストの数が増えれば，オペレータのエラーが起こる可
能性はずっと高くなる．一度テストを自動化してからは，ずっとよい結果が得ら
れるようになった．

%The key to automated testing is twofold:
%\begin{itemize}
%\item always test for the same symptom, and
%\item always feed consistent input to the \hgcmd{bisect} command.
%\end{itemize}
%In my tutorial example above, the \command{grep} command tests for the
%symptom, and the \texttt{if} statement takes the result of this check
%and ensures that we always feed the same input to the \hgcmd{bisect}
%command.  The \texttt{mytest} function marries these together in a
%reproducible way, so that every test is uniform and consistent.

テストを自動化するキーは2つある．
\begin{itemize}
 \item 常に同じ兆候をテストする．そして
 \item 常に\hgcmd{bisect}コマンドに一貫した入力を行う．
\end{itemize}
上のチュートリアル例では\command{grep}コマンドが兆候をテストしており，
\texttt{if}文がこのチェックの結果を取り，常に同じ入力が\hgcmd{bisect}コ
マンドになされるようになっていた．\texttt{mytest}関数は，再現可能な方法
で，これらを結びつけ，ここのテストが一様で一貫するようになっていた．


%\subsection{Check your results}
\subsection{結果をチェックする}

%Because the output of a \hgcmd{bisect} search is only as good as the
%input you give it, don't take the changeset it reports as the
%absolute truth.  A simple way to cross-check its report is to manually
%run your test at each of the following changesets:
%\begin{itemize}
%\item The changeset that it reports as the first bad revision.  Your
%  test should still report this as bad.
%\item The parent of that changeset (either parent, if it's a merge).
%  Your test should report this changeset as good.
%\item A child of that changeset.  Your test should report this
%  changeset as bad.
%\end{itemize}

\hgcmd{bisect}サーチの出力は，ユーザの入力が正しい場合に限って正しいので，
コマンドが報告するチェンジセットを絶対に正しいと考えてはいけない．報告の
クロスチェックを行う単純な方法は，以下のチェンジセットに対して，手動でテ
ストを行うことである．
\begin{itemize}
 \item 最初のbadリビジョンとして報告されるチェンジセット．これについてテ
       ストはbadとなる筈である
 \item そのチェンジセットの親（マージされているなら両方の親）．テストは
       goodになる筈である
 \item 最初のbadリビジョンとして報告されるチェンジセットの子．テストは
       badとなる筈である
\end{itemize}

%\subsection{Beware interference between bugs}
\subsection{バグ同士の相互干渉に留意する}

%It's possible that your search for one bug could be disrupted by the
%presence of another.  For example, let's say your software crashes at
%revision 100, and worked correctly at revision 50.  Unknown to you,
%someone else introduced a different crashing bug at revision 60, and
%fixed it at revision 80.  This could distort your results in one of
%several ways.

一つのバグに対するサーチがその他のバグの存在で混乱させられることが有り得
る．例えばソフトウェアがリビジョン100でクラッシュし，リビジョン50で動作
したとする．あなたには未知だが，誰か別の人がリビジョン60で他のクラッシュ
するバグを持ち込み，リビジョン80で修正したとする．これは結果を複数の方向
へ捩曲げ得る．

%It is possible that this other bug completely ``masks'' yours, which
%is to say that it occurs before your bug has a chance to manifest
%itself.If you can't avoid that other bug (for example, it prevents
%your project from building), and so can't tell whether your bug is
%present in a particular changeset, the \hgcmd{bisect} command cannot
%help you directly.  Instead, you can mark a changeset as untested by
%running \hgcmdargs{bisect}{--skip}.

この別のバグが追いかけているバグを完全にマスクしてしまうことも有り得る．
追いかけているバグが明らかになる前にこれが起きることも有り得る．他のバグ
が防ぎ切れないなら，バグが特定のチェンジセットに含まれると言うこともでき
ない．\hgcmd{bisect}コマンドは直接あなたを助けることができない．その代わ
り，あるチェンジセットを\hgcmdargs{bisect}{--skip}によって未テストとマー
クすることができる．


%A different problem could arise if your test for a bug's presence is
%not specific enough.  If you check for ``my program crashes'', then
%both your crashing bug and an unrelated crashing bug that masks it
%will look like the same thing, and mislead \hgcmd{bisect}.

バグのテストが十分に詳細でなかった場合，別の問題が起こり得る．プログラム
がクラッシュするかどうかをチェックしている時，追跡しているクラッシュバグ
と，それとは無関係なクラッシュバグが混在ているとこれらは同じに見えてしま
い，結果的にチェックをマスクしてしまい，\hgcmd{bisect}をミスリードする．


%Another useful situation in which to use \hgcmdargs{bisect}{--skip} is
%if you can't test a revision because your project was in a broken and
%hence untestable state at that revision, perhaps because someone
%checked in a change that prevented the project from building.

\hgcmdargs{bisect}{--skip}が有効な別の例として，ビルド不能になる変更が
チェックインされたリビジョンがあり，これを飛ばさなければテストができない
ような状況がある．

%\subsection{Bracket your search lazily}
\subsection{探索を怠惰にブラケットする}

%Choosing the first ``good'' and ``bad'' changesets that will mark the
%end points of your search is often easy,but it bears a little
%discussion nevertheless.  From the perspective of \hgcmd{bisect}, the
%``newest'' changeset is conventionally ``bad'', and the older
%changeset is ``good''.

最初のgoodとbadチェンジセットの組を選び，サーチ範囲を指定するのは多くの
場合簡単だが，若干の議論の余地がある．\hgcmd{bisect}から見た時，最新のチェ
ンジセットはbadで，古いチェンジセットはgoodとなる．

%If you're having trouble remembering when a suitable ``good'' change
%was, so that you can tell \hgcmd{bisect}, you could do worse than
%testing changesets at random. Just remember to eliminate contenders
%that can't possibly exhibit the bug (perhaps because the feature with
%the bug isn't present yet) and those where another problem masks the
%bug (as I discussed above).

適切なgoodチェンジセットを覚えていない時，\hgcmd{bisect}にそれを指定する
と，ランダムに選ぶよりも悪い探索を行う可能性がある．バグを示さない（おそ
らくバグのある機能が実装されていない）チェンジセットと，他の問題が追跡中
のバグをマスクしてしまうようなチェンジセットのみを消去することを覚えてお
くべきだ．

%Even if you end up ``early'' by thousands of changesets or months of
%history, you will only add a handful of tests to the total number that
%\hgcmd{bisect} must perform, thanks to its logarithmic behaviour.

\hgcmd{bisect}が行わなければならないテストの回数は，対象とするチェンジセッ
トの対数に比例するため，数ヵ月に及ぶ履歴の中の数千のチェンジセットの中に
対しても少数のテストを追加するだけで済む．


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