view ja/undo.tex @ 835:8a3041e6f3cb

reflect comments by Hiroshi Someya.

%\chapter{Finding and fixing your mistakes}
\chapter{$B%_%9$NH/8+$H=$@5(B}
\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.

$B%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$K$O?M$NHH$7$?4V0c$$$r$&$^$/=hM}$9$k5!G=$,(B
$B5a$a$i$l$F$$$k!%$3$N>O$G$O!$%W%m%8%'%/%H$K5/$3$jF@$kLdBj$N2r7h$KMxMQ2DG=(B
$B$J%F%/%K%C%/$K$D$$$F=R$Y$k!%(BMercurial$B$K$OLdBj$N$"$k%=!<%9$r@Z$jJ,$1!$=hM}(B
$B$9$k6/NO$J5!G=$,$"$k!%(B


%\section{Erasing local history}
\section{$B%m!<%+%k%R%9%H%j!<$r>C5n$9$k(B}

%\subsection{The accidental commit}
\subsection{$B%"%/%7%G%s%H$K$h$k%3%_%C%H(B}

%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.

$BI.<T$K$O%?%$%T%s%0Cf$K9M$($k$h$j$b@h$K;X$,F0$$$F$7$^$&JJ$,0JA0$+$i$"$j!$(B
$B$?$^$K$3$l$,5/$-$k$H!$IT40A4$@$C$?$j4V0c$C$?FbMF$N%A%'%s%8%;%C%H$r%3%_%C(B
$B%H$7$F$7$^$&!%I.<T$N>l9g!$IT40A4$J%A%'%s%8%;%C%H$NE57?$O?7$7$$%=!<%9%U%!(B
$B%$%k$r:n@.$7$?$N$K(B\hgcmd{add}$B$rK:$l$k$3$H$G!$(B``$B4V0c$C$?FbMF(B''$B$N%3%_%C%H(B
$B$O$"$^$j5/$-$J$$$,!$$d$O$jF1$8$h$&$KLq2p$G$"$k!%(B


%\subsection{Rolling back a transaction}
\subsection{$B%H%i%s%6%/%7%g%s$N%m!<%k%P%C%/(B}
\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}$B@a$G!$(BMercurial$B$O%j%]%8%H%j$X$N8D!9$NJQ99$r(B\emph{$B%H(B
$B%i%s%6%/%7%g%s(B}$B$H$7$F07$&$H$$$&$3$H$r=R$Y$?!%(BMercurial$B$O!$JL$N%j%]%8%H%j(B
$B$X$N%A%'%s%8%;%C%H$N%3%_%C%H$dJQ99$N(Bpull$B$r5-21$7$F$$$k!%%f!<%6$O(Bundo$B$7$?(B
$B$j!$0l2s$K8B$j%"%/%7%g%s$r(B\hgcmd{rollback}$B%3%^%s%I$G(B\emph{$B%m!<%k%P%C%/(B}$B$9(B
$B$k$3$H$,$G$-$k!%(B($B$3$N%3%^%s%I$N=EMW$J@)Ls$K$D$$$F$O(B
\ref{sec:undo:rollback-after-push}$B$r;2>H$N$3$H!%(B)


%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.

$BI.<T$,NI$/5/$3$9%_%9$O!$?7$7$$%U%!%$%k$r:n@.$7$?%A%'%s%8%;%C%H$r%3%_%C%H(B
$B$9$k;~$K(B\hgcmd{add}$B$N<B9T$rK:$l$k$b$N$G$"$k!%(B
\interaction{rollback.commit}
$B%3%_%C%H8e$N(B\hgcmd{status}$B$N=PNO$r8+$k$H!$D>$A$K%(%i!<$rI=<($7$F$$$k$3$H(B
$B$,$o$+$k!%(B
\interaction{rollback.status}
$B%3%_%C%H$O(B\filename{a}$B$X$NJQ99$r4^$s$G$$$k$,!$(B\filename{b}$B$X$NJQ99$O4^$s(B
$B$G$$$J$$!%$3$3$G;d$,F1N=$H6&M-$7$F$$$k%j%]%8%H%j$X%A%'%s%8%;%C%H$N%W%C%7%e(B
$B$r9T$C$?$H$7$?$i!$H`$i$,JQ99$r%W%k$7$?;~!$(B\filename{a}$B$NCf$N2?$+$,H`$i(B
$B$N%j%]%8%H%j$K4^$^$l$J$$(B\filename{b}$B$X$N;2>H$r9T$&2DG=@-$O9b$$!%$=$&$J$C(B
$B$?$iI.<T$OF1N=$NE\$j$rGc$&$3$H$K$J$k$@$m$&!%(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}

$B$7$+$79%1?$K$b%A%'%s%8%;%C%H$r%W%C%7%e$9$kA0$K%(%i!<$K5$$E$$$?>l9g!$(B
\hgcmd{rollback}$B%3%^%s%I$r;HMQ$9$k$3$H$G(BMercurial$B$+$i:G8e$N99?7$r<h$j=|(B
$B$/$3$H$,$G$-$k!%(B
\interaction{rollback.rollback}
$B%A%'%s%8%;%C%H$O%j%]%8%H%j$NMzNr$K$b$O$dB8:_$;$:!$%o!<%-%s%0%G%#%l%/%H%j(B
$B$N(B\filename{a}$B$OJQ99$5$l$?$HG'<1$5$l$k!%%3%_%C%H$7$F%m!<%k%P%C%/$9$k$H!$(B
$B%o!<%-%s%0%G%#%l%/%H%j$O40A4$K%3%_%C%HA0$N>uBV$K$J$j!$%A%'%s%8%;%C%H$O40(B
$BA4$K>C5n$5$l$k!%$3$N>uBV$G0BA4$K(B\hgcmd{add} \filename{b}$B$7!$$b$&0lEY(B
commit$B$9$k$3$H$,$G$-$k!%(B
\interaction{rollback.rollback}

%\subsection{The erroneous pull}
\subsection{$B8m$C$?%W%k(B}

%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$B$r;H$C$FJL!9$N3+H/%V%i%s%A$rJL!9$N%j%]%8%H%j$G4IM}$9$k$3$H$,$h$/(B
$B$"$k!%$"$J$?$N3+H/%A!<%`$O%W%m%8%'%/%H$N%j%j!<%9(B0.9$B$N$?$a$K(B1$B$D$N6&M-%j%](B
$B%8%H%j$r;}$A!$%j%j!<%9(B1.0$B$N$?$a$K0[$J$kJQ99$r;}$C$?$b$&0l$DJL$N%j%]%8%H(B
$B%j$r$b$C$F$$$k!%(B

%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.

$B$3$3$G$"$J$?$O8m$C$F%m!<%+%k$N(B0.9$B%j%]%8%H%j$K6&M-(B1.0$B%j%]%8%H%j$+$i%W%k$7(B
$B$?$H$9$k!%:G0-$N>l9g!$Cm0U$rBU$C$F!$$3$l$r6&M-$N(B0.9$B%j%]%8%H%j$K=q$-La$7$F(B
$B$7$^$$!$3+H/%A!<%`A4BN$r:.Mp$5$;$F$7$^$&$3$H$,M-$jF@$k!%!J$3$N>l9g$I$&$9(B
$B$l$P$$$$$N$+$K$D$$$F$O8e=R$9$k!%!K<B:]$K$O!$(BMercurial$B$O(Bpull$B85$N(BURL$B$rI=<((B
$B$9$k$7!$4V0c$C$?%j%]%8%H%j$+$i(Bpull$B$9$l$PBgNL$N%A%'%s%8%;%C%H$,I=<($5$l$k(B
$B$?$a!$B(:B$K2?$+$,$*$+$7$$$H5$$E$/$3$H$@$m$&!%(B

%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}$B%3%^%s%I$r<B9T$9$l$P!$:#%W%k$7$?$P$+$j$N%A%'%s%8%;%C%H$r(B
$BA4$F>C5n$9$k$3$H$,$G$-$k!%(BMercurial$B$O0l2s(B\hgcmd{pull}$B$K$h$k%H%i%s%6%/%7%g(B
$B%s$G$b$?$i$5$l$?A4$F$N%A%'%s%8%;%C%H$r%0%k!<%W2=$7$F$$$k$N$G!$(B
\hgcmd{rollback}$B$r0lEY<B9T$9$k$@$1$G!$%_%9$rA4$F$d$jD>$9$3$H$,$G$-$k!%(B


%\subsection{Rolling back is useless once you've pushed}
\subsection{$B0lEY%W%C%7%e$7$?8e$G$O%m!<%k%P%C%/$G$-$J$$(B}
\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.

$BB>$N%j%]%8%H%j$KJQ99$r%W%C%7%e$7$?8e$G$O(B\hgcmd{rollback}$B$N2ACM$O%<%m$G$"(B
$B$k!%JQ99$r%m!<%k%P%C%/$9$k$3$H$K$h$C$FJQ99$O40A4$K>CLG$9$k$,!$$=$l$O$"$J(B
$B$?$,(B\hgcmd{rollback}$B$r<B9T$7$?%j%]%8%H%j$K8B$C$F$N$3$H$G$"$k!%%m!<%k%P%C(B
$B%/$K$h$C$F!JJQ99$N!KMzNr<+BN$,$J$+$C$?$3$H$K$J$k$N$G!$JQ99$N>CLG$rB>$N%j(B
$B%]%8%H%j$KGH5Z$5$;$k<jCJ$O$J$$!%(B

%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.

$B$b$7$"$J$?$,B>$N%j%]%8%H%j!JFC$K6&M-%j%]%8%H%j!K$KJQ99$r%W%C%7%e$7$F$$$k(B
$B$N$J$i!$:$$C$?;vBV$,5/$3$C$F$*$j!$JL$NJ}K!$G%_%9$+$iI|5l$9$kI,MW$,$"$k!%(B
$B%A%'%s%8%;%C%H$r$I$3$+$X%W%C%7%e$7$?8e$G%m!<%k%P%C%/$7!$%W%C%7%e@h$N%j%](B
$B%8%H%j$+$i:F$S%W%k$7$?>l9g!$%A%'%s%8%;%C%H$,%m!<%+%k%j%]%8%H%j$K:F$S8=$l(B
$B$k!%(B

%(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.)

$B!J$b$7%m!<%k%P%C%/$7$?$$%A%'%s%8%;%C%H$,%W%C%7%e@h$N%j%]%8%H%j$G:G?7$G$"(B
$B$j!$$+$D!$C/$b$=$l$r%W%k$7$F$$$J$$$3$H$,3N<B$G$"$k>l9g$O!$%W%C%7%e@h$N%j(B
$B%]%8%H%j$G%m!<%k%P%C%/$9$k$3$H$,2DG=$@$,!$$3$NJ}K!$O3N<B$G$O$J$$$H$$$&$3(B
$B$H$r4N$KL?$8$F$*$/$Y$-$G$"$k!%$3$NJ}K!$OD>@\%3%s%H%m!<%k$G$-$J$+$C$?$j!$(B
$B$=$NJ}K!$rK:$l$F$7$^$C$?%j%]%8%H%j$X$NJQ99$N=$@5$K$O;H$($J$$!%!K(B


%\subsection{You can only roll back once}
\subsection{$B%m!<%k%P%C%/$O0l2s$N$_(B}

%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$B$O%H%i%s%6%/%7%g%s%m%0$K$=$N%j%]%8%H%j$K5/$3$C$?:G$b?7$7$$%H%i%s(B
$B%6%/%7%g%s0l2sJ,$N$_$r5-O?$7$F$$$k!%%m!<%k%P%C%/0l2sKh$K0l$DA0$N%j%S%8%g(B
$B%s$KLa$k$o$1$G$O$J$$!%(B
\interaction{rollback.twice}
$B%j%]%8%H%jFb$G0lEY%m!<%k%P%C%/$7$?$i!$JL$N%3%_%C%H$r$9$k$+%W%k$r$9$k$^(B
$B$G%m!<%k%P%C%/$O$G$-$J$$!%(B


%\section{Reverting the mistaken change}
\section{$B4V0c$C$?JQ99$r85$KLa$9(B}

%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.)

$B%U%!%$%k$KJQ99$r2C$($?8e$G!$JQ99$,I,MW$G$J$$$HJ,$+$j!$$^$@%3%_%C%H$5$l$F(B
$B$$$J$$;~$O(B\hgcmd{revert}$B%3%^%s%I$r;H$&$3$H$,$G$-$k!%$3$N%3%^%s%I$O%o!<%-(B
$B%s%0%G%#%l%/%H%j$N?F%A%'%s%8%;%C%H$r;2>H$7!$%U%!%$%k$NFbMF$r%A%'%s%8%;%C(B
$B%H$N>uBV$KLa$9!%!J$3$l$O$"$J$?$,2C$($?JQ99$r$/$I$/$I$7$/=R$Y$?$b$N$G$"(B
$B$k!%!K(B

%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}$B%3%^%s%I$,$I$N$h$&$KF0:n$9$k$+!$JL$N>.$5$JNc$G@bL@$9$k!%(B
$B$9$G$K(BMercurial$B$,4IM}$7$F$$$k%U%!%$%k$rJQ99$7$?$H$3$m$+$i;O$a$k!%(B
\interaction{daily.revert.modify}
$B$3$NJQ99$,I,MW$G$J$$>l9g!$C1$K%U%!%$%k$K(B\hgcmd{revert}$B$r<B9T$9$l$P$h$$!%(B
\interaction{daily.revert.unmodify}
\hgcmd{revert}$B%3%^%s%I$O0BA4$N$?$a(B\filename{.orig}$B$H$$$&%U%!%$%kL>$GJQ99(B
$B$r%;!<%V$9$k!%(B
\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}$B%3%^%s%I$,07$($k%1!<%9$K$D$$$F$^$H$a$k!%$h$j>\$7$$@bL@$O!$(B
$B8e$N@a$G9T$&!%(B

\begin{itemize}
\item $B%U%!%$%k$rJQ99$7$?>l9g!$(B\hgcmd{revert}$B$O%U%!%$%k$rJQ99$5$l$kA0$N>u(B
      $BBV$KLa$9!%(B
\item \hgcmd{add}$B$r<B9T$7$?>l9g!$(B\hgcmd{revert}$B$O(Badd$B$r<h$j>C$9$,!$%U%!%$(B
      $B%k<+BN$O$=$N$^$^<j$r?($l$:$K;D$9!%(B
\item Mercurial$B$rA`:n$;$:$K%U%!%$%k$r>C5n$7$F$$$?>l9g!$(B\hgcmd{revert}$B$O(B
      $B%U%!%$%k$rJQ99A0$N>uBV$GI|85$9$k(B
\item \hgcmd{remove}$B%3%^%s%I$G%U%!%$%k$r>C5n$7$F$$$?>l9g!$JQ99A0$N>uBV$G(B
      $B%U%!%$%k$rI|85$9$k!%(B
\end{itemize}


%\subsection{File management errors}
\subsection{$B%U%!%$%k4IM}$N%_%9(B}
\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}$B%3%^%s%I$OC1$KJQ99$7$?%U%!%$%k$rLa$9$@$1$G$J$/!$(B
\hgcmd{add}$B!$(B\hgcmd{remove}$B$H$$$C$?(BMercurial$B$N%U%!%$%kA`:n%3%^%s%I$N7k2L(B
$B$r<h$j>C$9$3$H$,$G$-$k!%(B

%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}$B$G%U%!%$%k$rDI2C$7$?8e$G!$(BMercurial$B$KDI@W$5$;$kI,MW$,$J$$$HJ,(B
$B$+$C$?;~!$(B\hgcmd{revert}$B$G(Badd$B$r<h$j>C$9$3$H$,$G$-$k!%(B\hgcmd{revert}$B$O%U%!(B
$B%$%k$N%^!<%/$r>C$9$@$1$G!$%U%!%$%k$NCf?H$O0l@ZJQ99$7$J$$$N$G?4G[$9$kI,MW(B
$B$O$J$$!%(B
\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}

$BF1MM$K!$(B\hgcmd{remove}$B%3%^%s%I$G%U%!%$%k$r>C5n$7$?;~!$(B\hgcmd{revert}$B%3%^(B
$B%s%I$G%o!<%-%s%0%G%#%l%/%H%j$N?F$NFbMF$K%U%!%$%k$rI|85$9$k$3$H$,$G$-$k!%(B
\interaction{daily.revert.remove}
$B$^$?(BMercurial$B$r;H$o$:$K<j$G>C$7$?%U%!%$%k$K$D$$$FF1$8A`:n$GI|85$9$k$3$H(B
$B$,$G$-$k!%!J(BMercurial$B$NMQ8l$G$3$l$r(Bmissing$B$H8F$s$G$$$?$3$H$r;W$$=P$7$FM_(B
$B$7$$!%!K(B
\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}$B%3%^%s%I$r<h$j>C$7$?>l9g!$%3%T!<@h$N%U%!%$%k$O%o!<%-%s%0%G%#(B
$B%l%/%H%j$K;D$k$,(BMercurial$B$+$i$O4IM}$5$l$J$$!%%3%T!<A`:n<+BN%3%T!<85%U%!%$(B
$B%k$K1F6A$rM?$($J$$$?$a!$<h$j>C$7$K$h$C$F%3%T!<85%U%!%$%k$,1F6A$r<u$1$k$3(B
$B$H$b$J$$!%(B


%\subsubsection{A slightly special case: reverting a rename}
\subsubsection{$B$d$dFC<l$J%1!<%9!'%j%M!<%`$N<h$j>C$7(B}

%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}$B$7$?8e$G$O!$>/$7N10U$7$F$*$/$Y$-E@$,$"$k!%%j%M!<%`8e$K(B
\hgcmd{revert}$B$7$?>l9g!$$3$3$G@bL@$9$k$h$&$K!$%j%M!<%`$7$?%U%!%$%k$NL>A0(B
$B$r;XDj$9$k$@$1$G$OIT==J,$G$"$k!%(B
\interaction{daily.revert.rename}
\hgcmd{status}$B$N=PNO$+$iJ,$+$k$h$&$K!$%j%M!<%`@h$N%U%!%$%k$O$b$O$d(Badd$B$5(B
$B$l$?07$$$K$J$C$F$$$J$$!%$7$+$7%j%M!<%`(B\emph{$B85(B}$B$N%U%!%$%k$O$^$@>C5n$5$l(B
$B$?$^$^$K$J$C$F$$$k!%$3$l$O!J>/$J$/$H$bI.<T$K$H$C$F!KHsD>46E*$@$,!$<h$j07(B
$B$$$O4JC1$G$"$k!%(B
\interaction{daily.revert.rename-orig}
\hgcmd{rename}$B$r<h$j>C$9:]$K$O!$85$N%U%!%$%k$H%j%M!<%`8e$N%U%!%$%k(B
\emph{$BN>J}(B}$B$r;XDj$9$kI,MW$,$"$k!%(B

%(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.)

$B!J0lJ}!$%j%M!<%`$7$?8e$K%j%M!<%`@h$N%U%!%$%k$rJT=8$7!$%j%M!<%`$NA08e$N%U%!(B
$B%$%kL>$r;XDj$7$F<h$j>C$7$r9T$$!$(BMercurial$B$,%j%M!<%`$N:]$K>C5n$5$l$?%U%!(B
$B%$%k$r=$I|$9$k$H!$$3$N%U%!%$%k$OJT=8A0$N>uBV$K$J$C$F$$$k!%%j%M!<%`8e$N%U%!(B
$B%$%k$X$NJQ99$,%j%M!<%`A0$N%U%!%$%k$K;D$k$h$&$K$9$k$K$O!$%3%T!<$r:n$C$F$*(B
$B$/I,MW$,$"$k!%!K(B

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

$B%j%M!<%`$rI|85$9$k;~$K5/$3$kLq2p$4$H$O$*$=$i$/(BMercurial$B$N%P%0$H8@$($k$+(B
$B$b$7$l$J$$!%(B


%\section{Dealing with committed changes}
\section{$B%3%_%C%H$5$l$?JQ99$N07$$(B}

%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$r%3%_%C%H$7$?8e$GJL$N(B$b$$B$r%3%_%C%H$7!$$3$3$G(B$a$$B$O8m$j$G$"$k$3$H$K5$$,(B
$B$D$$$?>l9g$r9M$($k!%(BMercurial$B$O%A%'%s%8%;%C%HA4BN$H%A%'%s%8%;%C%H$N0lItJ,(B
$B$r<j$G%P%C%/%"%&%H$9$k$h$&$KB%$9!%(B

%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}.

$B$3$N@a$rFI$`A0$K!$(B\hgcmd{backout}$B%3%^%s%I$OMzNr$K(B\emph{$BDI2C(B}$B$9$k$3$H$G<h(B
$B$j>C$7A`:n$r9T$&$3$H$r3P$($F$*$$$FM_$7$$!%JQ99$d>C5n$G$O$J$$!%%P%0$N=$(B
$B@5$N$?$a$KLrN)$D%D!<%k$@$,!$JQ99$N<h$j>C$7$N$?$a$KMQ$$$k$HGKLGE*$J7k2L$r(B
$B$b$?$i$9!%8e<T$NL\E*$N$?$a$K$O(B\ref{sec:undo:aaaiiieee}$B$r;2>H$N$3$H!%(B

%\subsection{Backing out a changeset}
\subsection{$B%A%'%s%8%;%C%H$N%P%C%/%"%&%H(B}

%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}$B%3%^%s%I$O%A%'%s%8%;%C%HA4BN$N:nMQ$rBG$A>C$9!%(BMercurial$B$N(B
$BMzNr$OITJQ$J$N$G!$$3$N%3%^%s%I$O<h$j>C$7$?$$%A%'%s%8%;%C%H$r<h$j=|$/$b$N(B
$B$G$O(B\emph{$B$J$$(B}$B!%$=$NBe$o$j!$<h$j=|$-$?$$%A%'%s%8%;%C%H$N(B\emph{$B5U(B}$B$NF/$-(B
$B$N?7$?$J%A%'%s%8%;%C%H$r@8@.$9$k!%(B

%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}$B%3%^%s%I$NF0:n$O$d$dJ#;($J$N$G!$Nc$r5s$2$F@bL@$9$k$3$H$K(B
$B$9$k!%$^$:$$$/$D$+$NC1=c$JJQ99$N$"$k%j%]%8%H%j$r9M$($k!%(B
\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}$B%3%^%s%I$O%P%C%/%"%&%H$9$Y$-%A%'%s%8%;%C%H$N(BID$B$r0l$D0z?t$K(B
$B<h$k!%(B\hgcmd{backout}$B$O%G%U%)%k%H$G%3%_%C%H%a%C%;!<%8F~NO$N$?$a$K%F%-%9%H(B
$B%(%G%#%?$r5/F0$9$k$N$G!%%P%C%/%"%&%H$NM}M3$r5-O?$7$F$*$/!%$3$NNc$G$O(B
\hgopt{backout}{-m}$B%*%W%7%g%s$r;H$C$F%3%_%C%H%a%C%;!<%8$r5-O?$7$F$$$k!%(B


%\subsection{Backing out the tip changeset}
\subsection{tip$B%A%'%s%8%;%C%H$r%P%C%/%"%&%H$9$k(B}

%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.

$B:G8e$K%3%_%C%H$7$?%A%'%s%8%;%C%H$r%P%C%/%"%&%H$9$k$3$H$+$i;O$a$k!%(B
\interaction{backout.simple}
\filename{myfile}$B$N(B2$B9TL\$,$J$/$J$C$F$$$k$N$,J,$+$k$H;W$&!%(B\hgcmd{log}$B$r(B
$B8+$F$_$k$H!$(B\hgcmd{backout}$B$,2?$r$7$?$N$+$,J,$+$k!%(B
\interaction{backout.simple.log}
\hgcmd{backout}$B$,@8@.$7$??7$7$$%A%'%s%8%;%C%H$O!$%P%C%/%"%&%H$7$?%A%'%s(B
$B%8%;%C%H$N;R$K$J$C$F$$$k!%(B\ref{fig:undo:backout}$B$O99?7MzNr$r?^<($7$?$b$N(B
$B$G!$M}2r$N=u$1$K$J$k$O$:$@!%?^$+$iJ,$+$k$h$&$KMzNr$O@~7A$G@09g$,<h$l$F$$$k!%(B

\begin{figure}[htb]
  \centering
  \grafix{undo-simple}
%  \caption{Backing out a change using the \hgcmd{backout} command}
  \caption{\hgcmd{backout}$B%3%^%s%I$r;H$C$F99?7$r%P%C%/%"%&%H(B}
  \label{fig:undo:backout}
\end{figure}

%\subsection{Backing out a non-tip change}
\subsection{tip$B$G$J$$JQ99$r%P%C%/%"%&%H$9$k(B}

%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}

$B:G8e$N%3%_%C%H0J30$NJQ99$r%P%C%/%"%&%H$7$?$$;~$O!$(B
\hgcmd{backout}$B$K(B\hgopt{backout}{--merge}$B%*%W%7%g%s$rIU$1$k!%(B
\interaction{backout.non-tip.clone}
$B$3$N%*%W%7%g%s$O$I$s$J%A%'%s%8%;%C%H$G$b0l2s$NF0:n$G9T$&$3$H$,$G$-!$<j(B
$BAa$/4JC1$G$"$k!%(B
\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}

$B%P%C%/%"%&%H$,=*$C$?$"$H$G(B\filename{myfile}$B$NCf?H$r8+$k$H!$(B1$BHVL\$H(B3$BHVL\(B
$B$NJQ99$@$1$,;D$C$F$*$j!$(B2$BHVL\$NJQ99$,>C$($F$$$k$3$H$,$o$+$k!%(B
\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.

$B?^(B\ref{fig:undo:backout-non-tip}$B$G<($5$l$?MzNr$G!$(BMercurial$B$O(B2$B$D$N%3%_%C(B
$B%H$r9T$C$F$$$k!%!J?^Cf$GH"$G<($5$l$?@aE@$O(BMercurial$B$,<+F0E*$K%3%_%C%H$7(B
$B$?JQ99$G$"$k!%!K%P%C%/%"%&%H%W%m%;%9$NA0$K(BMercurial$B$O!$8=:_$N%o!<%-%s%0%G%#(B
$B%l%/%H%j$N?F$,2?$G$"$k$+$r5-21$9$k!%$=$7$F%?!<%2%C%H$N%A%'%s%8%;%C%H$r<h(B
$B$j=|$-!$$3$l$r%A%'%s%8%;%C%H$H$7$F%3%_%C%H$9$k!%:G8e$K%o!<%-%s%0%G%#%l%/(B
$B%H%j$NA0$N?F$X%^!<%8$r9T$$!$%^!<%8$N7k2L$r%3%_%C%H$9$k!%(B

\begin{figure}[htb]
  \centering
  \grafix{undo-non-tip}
%  \caption{Automated backout of a non-tip change using the
 %  \hgcmd{backout} command}
  \caption{tip$B$G$J$$JQ99$r(B\hgcmd{backout}$B%3%^%s%I$G<+F0E*$K%P%C%/%"%&%H$9$k(B}
  \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.

$B:G=*E*$K!$$$$/$i$+$NM>7W$JMzNr$r;D$7$D$D!$<h$j=|$-$?$+$C$?%A%'%s%8%;%C%H(B
$B$N1F6A$r=|5n$7$F!$K>$`>uBV$KLa$9$3$H$,$G$-$F$$$k!%(B


%\subsubsection{Always use the \hgopt{backout}{--merge} option}
\subsubsection{$B>o$K(B\hgopt{backout}{--merge}$B%*%W%7%g%s$r;H$&(B}

%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.

$B%P%C%/%"%&%H$7$h$&$H$9$k%A%'%s%8%;%C%H$,%A%C%W$+%A%C%W$G$J$$$+$K$+JQ$o$i(B
$B$:!$(B\hgcmd{backout}$B%3%^%s%I$r;H$*$&$H$9$k;~$O(B\emph{$B>o$K(B}
\hgopt{backout}{--merge}$B%*%W%7%g%s$r;H$&$Y$-$G$"$k!%BP>]$,%A%C%W$G$"$k>l(B
$B9g$OITMW$J%^!<%8$r;n$_$k$3$H$O$J$$$?$a!$>o$K$3$N%*%W%7%g%s$r;XDj$7$FLdBj(B
$B$J$$!%(B


%\subsection{Gaining more control of the backout process}
\subsection{$B%P%C%/%"%&%H%W%m%;%9$r$h$j:Y$+$/@)8f$9$k(B}

%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.

$BJQ99$r%P%C%/%"%&%H$9$k:]!$>o$K(B\hgopt{backout}{--merge}$B%*%W%7%g%s$r;H$&$3(B
$B$H$r4+$a$?$,!$(B\hgcmd{backout}$B%3%^%s%I$G$O!$%P%C%/%"%&%H$9$k%A%'%s%8%;%C%H(B
$B$r$I$N$h$&$K%^!<%8$9$k$+;XDj$9$k$3$H$,$G$-$k!%%P%C%/%"%&%H%W%m%;%9$r<j$G(B
$B%3%s%H%m!<%k$9$kI,MW$O$[$H$s$I$J$$$O$:$@$,!$(B\hgcmd{backout}$B%3%^%s%I$,<+F0(B
$B$G$I$N$h$&$KF0:n$7$F$$$k$N$+M}2r$9$k$N$K$OLrN)$D$+$bCN$l$J$$!%F0:n$r@bL@(B
$B$9$k$?$a$K:G=i$N%j%]%8%H%j$N%/%m!<%s$r!$%P%C%/%"%&%H$r=|$$$F:n$C$F;O$a$k(B
$B$3$H$K$7$h$&!%(B

%\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}

$BA0$K;H$C$?Nc$N$h$&$K!$(B3$BHVL\$N%A%'%s%8%;%C%H$r%3%_%C%H$7$?8e$G!$$=$N?F$r(B
$B%P%C%/%"%&%H$7$F2?$,5/$-$k$+8+$F$_$h$&!%(B
\interaction{backout.manual.backout} 

$BA0$NNc$HF1MM$K!$?7$7$$%A%'%s%8%;%C%H$O%P%C%/%"%&%H$7$?%A%'%s%8%;%C%H$N;R(B
$B$K$"$?$k!%$7$?$,$C$F?7$7$$%X%C%I$O%A%C%W$N;R$G$O(B\emph{$B$J$$(B}$B!%(B
\hgcmd{backout}$B%3%^%s%I$O$3$N?F;R4X78$K$D$$$F$+$J$j$O$C$-$j$HI=<($9$k!%(B
\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).

$B$3$3$G$b%j%S%8%g%sMzNr$N%0%i%U(B\ref{fig:undo:backout-manual}$B$r8+$l$P!$2?$,(B
$B5/$-$F$$$k$N$+M}2r$7$d$9$$!%%A%C%W0J30$NJQ99$r%P%C%/%"%&%H$9$k$?$a$K(B
\hgcmd{backout}$B$r;H$C$?;~!$(BMercurial$B$,?7$7$$%X%C%I$r%j%]%8%H%j$KDI2C$9$k(B
$B$N$,$o$+$k!%!J;M3Q$G<($5$l$?%3%_%C%H!%!K(B

\begin{figure}[htb]
  \centering
  \grafix{undo-manual}
%  \caption{Backing out a change using the \hgcmd{backout} command}
  \caption{\hgcmd{backout}$B%3%^%s%I$K$h$kJQ99$N%P%C%/%"%&%H(B}
  \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}$B%3%^%s%I$O!$40N;$7$?8e!$%P%C%/%"%&%H%A%'%s%8%;%C%H$r%o!<%-(B
$B%s%0%G%#%l%/%H%j$N?F$H$7$F;D$9!%(B
\interaction{backout.manual.parents}
$B$3$3$G(B2$B$D$N3VN%$5$l$?JQ99$N%;%C%H$,B8:_$9$k$3$H$K$J$k!%(B
\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}.

$B:#$3$3$G(B\filename{myfile}$B$NFbMF$r8+$?$$$H$9$k!%:G=i$NJQ99$O%P%C%/%"%&%H$7(B
$B$F$$$J$$$N$GB8:_$7$F$$$k$O$:$G$"$k!%(B2$BHVL\$NJQ99$O%P%C%/%"%&%H$7$?$N$G>C(B
$B$($FL5$/$J$C$F$$$k$O$:$@!%(B3$BHVL\$NJQ99$OMzNr%0%i%U$GJ,N%$7$?%X%C%I$H$7$F(B
$BI=<($5$l$k$?$a!$(B3$BHVL\$NJQ99$,(B\filename{myfile}$B$K$"$k$H$O4|BT$7$F$$$J$$!%(B
\interaction{backout.manual.cat}
3$BHVL\$NJQ99$r%U%!%$%k$KH?1G$5$;$k$?$a$K$O!$(B2$B$D$N%X%C%I$r%^!<%8$7$F$d$l$P(B
$B$h$$!%(B
\interaction{backout.manual.merge}
$B$=$N8e$G$O%j%]%8%H%j$NMzNr$N%0%i%U$O?^(B
\ref{fig:undo:backout-manual-merge}$B$N$h$&$K$J$k(B

\begin{figure}[htb]
  \centering
  \grafix{undo-manual-merge}
%  \caption{Manually merging a backout change}
  \caption{$B%P%C%/%"%&%H%A%'%s%8$N<jF0$K$h$k%^!<%8(B}
  \label{fig:undo:backout-manual-merge}
\end{figure}

%\subsection{Why \hgcmd{backout} works as it does}
\subsection{$B$J$<(B\hgcmd{backout}$B$O$3$N$h$&$KF0:n$9$k$N$+(B}

%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}$B$,$I$N$h$&$KF0:n$9$k$+407k$K@bL@$9$k$H0J2<$N$h$&$K$J$k!%(B
\begin{enumerate}
 \item $B%o!<%-%s%0%G%#%l%/%H%j$,%/%j!<%s$G$"$k$3$H$r3NG'$9$k!%(Bi.e.\hgcmd{status}
      $B$,6u$G$"$k$3$H$r3NG'$9$k(B
 \item $B8=:_$N%o!<%-%s%0%G%#%l%/%H%j$N?F$r5-21$9$k!%$3$N%A%'%s%8%;%C%H$r(B
       \texttt{orig}$B$H8F$V$3$H$K$9$k!%(B
 \item $B%o!<%-%s%0%G%#%l%/%H%j$r!$%P%C%/%"%&%H$7$?%A%'%s%8%;%C%H$NFbMF$K(B
       $B$9$k$?$a$K(B\hgcmd{update}$B$HEy2A$JF0:n$r9T$&!%$3$N%A%'%s%8%;%C%H(B
       $B$r(B\texttt{backout}$B$H8F$V!%(B
 \item $B$=$N%A%'%s%8%;%C%H$N?F$r8+$D$1=P$9!%$3$N%A%'%s%8%;%C%H$r(B
       \texttt{parent}$B$H8F$V$3$H$K$9$k!%(B
 \item \texttt{backout}$B%A%'%s%8%;%C%H$,1F6A$9$k3F!9$N%U%!%$%k$KBP$7$F!$(B
       \hgcmdargs{revert}{-r parent}$B$HEy2A$JA`:n$r9T$$!$%A%'%s%8%;%C%H$,(B
       $B%3%_%C%H$5$l$kA0$N>uBV$KLa$9!%(B
 \item $B?7$7$$%A%'%s%8%;%C%H$N7k2L$r%3%_%C%H$9$k!%$3$N%A%'%s%8%;%C%H$O(B
       \texttt{backout}$B$r?F$K;}$D!%(B
 \item \hgopt{backout}{--merge}$B$r%3%^%s%I%i%$%s$+$iF~NO$7$?>l9g!$(B
       \texttt{orig}$B$H$N%^!<%8$r9T$$!$7k2L$r%3%_%C%H$9$k!%(B
\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}$B%3%^%s%I$r<BAu$9$kJL$NJ}K!$H$7$F!$(B\hgcmd{export}$B$G%P%C%/%"(B
$B%&%H$5$l$k$Y$-%A%'%s%8%;%C%H$r:9J,$H$7$F=PNO$7!$(B
\command{patch}$B$r(B\cmdopt{patch}{--reverse}$B%*%W%7%g%sIU$-$G8F$S!$%o!<%-%s(B
$B%0%G%#%l%/%H%j$NA`:n$r>JN,$7$F%j%P!<%9%Q%C%A$9$kJ}K!$,9M$($i$l$k!%(B
$B$3$NJ}K!$O$:$C$HC1=c$@$,!$$[$H$s$I$&$^$/F0$+$J$$!%(B

%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}$B$,%"%C%W%G!<%H!$%3%_%C%H!$%^!<%8!$%3%_%C%H$r9T$&M}M3$O!$(B
$B%P%C%/%"%&%H$9$Y$-JQ99$H8=:_$N%A%C%W$N4V$G!$%^!<%85!9=$,:G$bNI$$7k2L$rF@(B
$B$i$l$k$h$&$K$9$k$?$a$G$"$k!%(B

%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.

$B$b$7%W%m%8%'%/%H$NMzNr$NCf$G(B100$B%j%S%8%g%s$bAL$k$h$&$J%A%'%s%8%;%C%H$r%P%C(B
$B%/%"%&%H$9$k$H$9$l$P!$(B\command{patch}$B$,(Bdiff$B$rE,MQ$G$-$k2DG=@-$OL@$i$+$KDc(B
$B$$!%4V$K$"$kJQ99$,!$(B\command{patch}$B%3%^%s%I$,%Q%C%AE,MQ$N2DH]$rH=CG$9$k$?(B
$B$a$NJ8L.$r2u$7$F$$$k2DG=@-$,9b$$$+$i$G$"$k!%!J$3$NOC$,J,$+$i$J$$>l9g$O(B
\ref{sec:mq:patch}$B$N(B\command{patch}$B%3%^%s%I$K4X$9$k5DO@$r;2>H$7$FM_$7$$!%!K(B
$B$^$?!$(BMercurial$B$N%^!<%85!9=$O!$(B\command{patch}$B%3%^%s%I$,07$($J$$%U%!%$%k(B
$B$H%G%#%l%/%H%j$N%j%M!<%`!$%Q!<%_%C%7%g%sJQ99!$%P%$%J%j%U%!%$%k$X$NJQ99$J(B
$B$I$r07$&$3$H$,$G$-$k!%(B


%\section{Changes that should never have been}
\section{$BB8:_$9$Y$-$G$J$$JQ99(B}
\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.

$BBgDq$N>l9g!$(B\hgcmd{backout}$B$O$"$kJQ99$r<h$j>C$=$&$H$9$k:]$K;W$C$?$h$&$K5!(B
$BG=$9$k$O$:$G$"$k!%85!9$N%3%_%C%H$d$=$l$r<h$j=|$$$?;~$K2?$r$7$?$N$+1JB3E*(B
$B$J5-21$,;D$5$l$k!%(B

%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.

$B$=$l$G$b$?$^$K%j%]%8%H%j$KA4$/;D$7$?$/$J$$JQ99$r%3%_%C%H$7$F$7$^$&$3$H$,(B
$B$"$k!%$?$H$($P!$Hs>o$KJQ$J%3%_%C%H$d!$DL>o%_%9$H9M$($i$l$k$h$&$J%3%_%C%H!$(B
$B%=!<%9$@$1$G$O$J$/%W%m%8%'%/%H$N%*%V%8%'%/%H%U%!%$%k$b%3%_%C%H$7$F$7$^$&(B
$B$J$I$,M-$jF@$k!%%*%V%8%'%/%H%U%!%$%k$O8GM-$NCM$r;}$AF@$:!$$+$D(B\emph{$BBg$-(B
$B$$(B}$B!%$=$N$?$a!$%j%]%8%H%j$N%5%$%:$rA}$d$7!$%/%m!<%s$d%W%k$KM>7W$J;~4V$,3](B
$B$+$k$h$&$K$J$k!%(B

%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.

$BCc?'$N;fB^%3%_%C%H!JCc?'$N;fB^$rF,$KHo$j$?$$$0$i$$%P%D$N0-$$%3%_%C%H!K$K(B
$B;H$($k%*%W%7%g%s$K$D$$$F5DO@$9$kA0$K!$$$$/$D$+$N$&$^$/9T$+$J$$%"%W%m!<%A(B
$B$r=R$Y$?$$!%(B

%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$B$OMzNr$rN_@QE*$J$b$N$H$7$F07$&!%A4$F$NJQ99$O$=$l$K@hN)$DA4$F$NJQ(B
$B99$N>e$K$J$j$?$C$F$$$k!%0lHLE*$K8@$C$FGK2uE*$JJQ99$r2sHr$9$k$3$H$O$G$-$J(B
$B$$!%$?$C$?0l$D$NNc30$O%3%_%C%H$r9T$C$?D>8e$G!$B>$N%j%]%8%H%j$K%W%C%7%e(B
$B$b%W%k$b$5$l$F$$$J$$>l9g$G$"$k!%$=$N>l9g!$(B\ref{sec:undo:rollback}$B$N%;%/%7%g(B
$B%s$G>\$7$/?($l$?$h$&$K!$0BA4$K(B\hgcmd{rollback}$B$r<B9T$9$k$3$H$,$G$-$k!%(B

%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.

$B4V0c$C$?JQ99$rB>$N%j%]%8%H%j$K%W%C%7%e$7$?8e$G$b%m!<%+%k%3%T!<$NJQ99$r<h(B
$B$j>C$9$?$a$K0MA3$H$7$F(B\hgcmd{rollback}$B$r;H$&$3$H$,(B\emph{$B$G$-$k(B}$B$,!$$3$l$O(B
$B0U?^$7$?$h$&$J7k2L$K$O$J$i$J$$!%JQ99$O0MA3$H$7$F%j%b!<%H$N%j%]%8%H%j$K$O(B
$BB8:_$7$F$*$j!$<!$K%W%k$7$?;~$K$O%m!<%+%k%j%]%8%H%j$K$b8=$l$k!%(B

%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.

$B$3$N$h$&$J>u67$K$J$C$?;~!$$b$7$I$N%j%]%8%H%j$K$3$N4V0c$C$?JQ99$,GH5Z$7$F(B
$B$$$k$N$+$,L@$i$+$G$"$l$P!$$=$l$i$N%j%]%8%H%j$N0l$D0l$D$+$i!$JQ99$r<h$j=|(B
$B$/$3$H$r;n$_$k$3$H$,$G$-$k!%$3$l$O$b$A$m$sK~B-$N$$$/2r7hK!$G$O$J$$!%$b$7(B
$B0l$D$G$b>C5n$rK:$l$l$P!$JQ99$OLnJ|$7$K$J$C$F$*$j!$$5$i$K9-$,$j$&$k!%(B

%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.

$B$b$7(B1$B$D0J>e$N?7$?$JJQ99$r!$>C$7$?$$$H;W$C$F$$$kJQ99$N8e$K%3%_%C%H$7$F$$(B
$B$?$H$9$l$P!$;H$($k%*%W%7%g%s$O$5$i$K>/$J$/$J$k!%(BMercurial$B$O%A%'%s%8%;%C(B
$B%H$r$=$N$^$^$KMzNr$K7j$r3+$1$k$h$&$JJ}K!$rDs6!$7$F$$$J$$!%(B

%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 $BDI5-$NI,MW@-$"$j!%(B\texttt{examples}$B%G%#%l%/%H%jFb$N(B
\texttt{hg-replay}$B%9%/%j%W%H$O5!G=$9$k$,!$%A%'%s%8%;%C%H$N%^!<%8$r07$o$J(B
$B$$!%=EMW$J@)8B$G$"$k!%(B


%\subsection{Protect yourself from ``escaped'' changes}
\subsection{$B0oC&$7$?JQ99$+$i<+J,<+?H$r<i$k(B}

%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.

$B%m!<%+%k%j%]%8%H%j$K$$$/$D$+$NJQ99$r%3%_%C%H$7!$$=$l$i$,JL$N=j$K%W%C%7%e(B
$B$^$?$O%W%k$5$l$F$$$F!$I,$:$7$bBg:R32$H$O8@$($J$$!%$"$J$?$O$$$/$D$+$N%/%i(B
$B%9$N4V0c$C$?JQ99$+$i<+J,<+?H$G?H$r<i$k$3$H$,$G$-$k!%$3$l$O$"$J$?$N%A!<%`(B
$B$,Cf1{$N%j%]%8%H%j$+$iJQ99$r%W%k$7$F$$$k>l9g$OFC$K4JC1$G$"$k!%(B

%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.

$BCf1{%j%]%8%H%j$N>e$G!$JQ99E~Ce$K%U%C%/$r@_Dj$9$k!J(B\ref{chap:hook}$B$r;2>H!K(B
$B$3$H$G!$$"$k<o$N8m$C$?%A%'%s%8%;%C%H$,Cf1{%j%]%8%H%j$K%3%_%C%H$5$l$k$N$r(B
$B<+F0E*$KKI$0$3$H$,$G$-$k!%$=$N$h$&$J@_Dj$r9T$&$3$H$G!$$"$k<o$N8m$C$?%A%'(B
$B%s%8%;%C%H$OCf1{%j%]%8%H%j$KGH5Z$9$k$3$H$,$G$-$:!$;`LG$7$F$$$/798~$,$"(B
$B$k!%9%ET9g$J$3$H$K!$;`LG$OM[$K2pF~$9$kI,MW$J$/5/$-$k!#(B

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

$BNc$($P!$%A%'%s%8%;%C%H$r<B:]$K%3%s%Q%$%k$9$kJQ99E~Ce%U%C%/$O!$ITCm0U$K$h(B
$B$k%S%k%IITG=$rKI$0$3$H$,$G$-$k!%(B

%\section{Finding the source of a bug}
\section{$B%P%0$N860x$r8+$D$1$k(B}
\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.

$B%P%0$rH/@8$5$;$?%A%'%s%8%;%C%H$r%P%C%/%"%&%H$9$k$?$a$K$O!$$I$N%A%'%s%8%;%C(B
$B%H$G%P%0$N:.F~$,5/$-$?$N$+$rCN$i$M$P$J$i$J$$!%(BMercurial$B$O(B\hgcmd{bisect}
$B$H$$$&M-MQ$J%3%^%s%I$rDs6!$7$F$*$j!$$3$l$K$h$C$F%A%'%s%8%;%C%H$NFCDj$r<+(B
$BF02=$7!$%P%C%/%"%&%H$r6K$a$F8z2LE*$K9T$&$3$H$,$G$-$k!%(B

%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}$B%3%^%s%I$NGX8e$K$O!$%A%'%s%8%;%C%H$K$h$C$FC1=c$J%P%$%J%j%F(B
$B%9%H$G==J,<1JL2DG=$J5sF0$NJQ2=$,@8$l$k$H$$$&9M$(J}$,$"$k!%$"$J$?$O$I$N%3!<(B
$B%I$,JQ2=$r0z$-5/$3$7$?$N$+$O$o$+$i$J$$$,!$%P%0$,5/$-$F$$$k$+$r%F%9%H$9$k(B
$BJ}K!$OCN$C$F$$$k!%(B\hgcmd{bisect}$B%3%^%s%I$O!$%F%9%H$K$h$C$F%P%0$r0z$-5/$3(B
$B$7$?%A%'%s%8%;%C%H$rFCDj$9$k!%(B

%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}

$B0J2<$O$3$N%3%^%s%I$r$I$N$h$&$KE,MQ$G$-$k$N$+M}2r$r=u$1$k%7%J%j%*$G$"$k!%(B
\begin{itemize}
 \item $B%P%0$,5/$-$F$$$J$+$C$?:G$b?7$7$$%P!<%8%g%s$r3P$($F$$$k$,!$$I$N%P!<(B
       $B%8%g%s$G%P%0$,:.F~$7$?$+J,$+$i$J$$!%$3$3$G%P%$%J%j%F%9%H$r9T$$!$(B
       $B%P%0$NB8:_$rD4$Y$k!%(B
 \item $B%P%0$rBg5^$.$G=$@5$7!$$"$J$?$N%A!<%`$N%P%0%G!<%?%Y!<%9$r%/%m!<%:(B
       $B$9$k!%%P%0%G!<%?%Y!<%9$O$I$3$G%P%0$,=$@5$5$l$?$+$N%A%'%s%8%;%C%H(B
       $B$N(BID$B$rI,MW$H$9$k$,!$$"$J$?$O$I$N%A%'%s%8%;%C%H$G=$@5$5$l$?$+5-21(B
       $B$7$F$$$J$$!%$3$3$G$^$?%P%0$NB8:_$r%P%$%J%j%F%9%H$9$k!%(B
 \item $B$"$J$?$N%=%U%H%&%'%"$O@5$7$/F0$$$?$,!$0JA0B,Dj$7$?;~$h$j$b(B15\%$BCY(B
       $B$/$J$C$F$$$?!%$"$J$?$O$I$N%A%'%s%8%;%C%H$,$3$N@-G=Nt2=$r$b$?$i$7(B
       $B$?$N$+CN$j$?$$!%$3$N>l9g!$%P%$%J%j%F%9%H$GB.EY$rB,Dj$9$k!%(B
 \item $B=P2Y$9$k%W%m%8%'%/%H$N%3%s%]!<%M%s%H%5%$%:$,:G6aGzH/E*$KA}$($?!%(B
       $B$"$J$?$O%W%m%8%'%/%H$N%S%k%I$NJ}K!$K$J$s$i$+$NJQ2=$,5/$-$?$N$G$O(B
       $B$J$$$+$H5?$C$F$$$k!%(B
\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.

$B$3$NNc$+$i!$(B\hgcmd{bisect}$B%3%^%s%I$OC1$K%P%0$N=j:_$rC5$9$N$KLrN)$D$@$1$G(B
$B$O$J$/!"%P%$%J%j%F%9%H$rMQ0U$G$-$k$N$G$"$l$P!"%j%]%8%H%j$G5/$-$?$"$i$f$k(B
$BJQ2=!JC1$K%D%j!<$r%F%-%9%H%5!<%A$7$?$N$G$OH/8+$G$-$J$$JQ2=!K$rCN$k$N$K;H(B
$B$($k$3$H$,$o$+$k!#(B

%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''.

$B$3$3$G%5!<%A$N$I$N%Q!<%H$,$"$J$?$N@UG$$KB0$7!$$I$N%Q!<%H$,(BMercurial$B$KB0$9(B
$B$k$N$+L@3N$K$9$k$?$a$K>/$7$P$+$jMQ8l$rF3F~$9$k!%(B\emph{test}$B$O(B\emph{$B$"$J(B
$B$?(B}$B$,(B\hgcmd{bisect}$B$r<B9T$9$k;~$KA*$s$@%A%'%s%8%;%C%H$G$"$k!%(B
\emph{probe}$B$O(B\hgcmd{bisect}$B$,%j%S%8%g%s$,NI$$$+H=Dj$9$k%j%S%8%g%s$G$"$k!%(B
``bisect''$B$H$$$&C18l$r(B``\hgcmd{bisect}$B%3%^%s%I$r;H$C$F%5!<%A$9$k(B''$B$H$$$&(B
$B$3$H$NF15A8l$H$7$FL>;l$HF0;lN>J}$GMQ$$$k!%(B

%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.

$B%5!<%A%W%m%;%9$r<+F02=$9$kC1=c$JJ}K!$O!$A4$F$N%A%'%s%8%;%C%H$r(Bprobe$B$9$k$3(B
$B$H$G$"$k!%$7$+$7$3$l$OKX$s$I%9%1!<%k$7$J$$!%0l$D$N%A%'%s%8%;%C%H$N%A%'%C(B
$B%/$K(B10$BJ,$+$+$j!$%j%]%8%H%j$K%A%'%s%8%;%C%H$,(B10000$B$"$C$?$H$7$?$i!$iMDY$7$N(B
$B%"%W%m!<%A$O%P%0$rH/@8$5$;$?%A%'%s%8%;%C%H$NFCDj$KJ?6Q$G(B35$BF|$+$+$k!%%P%0(B
$B$,:G8e$N(B500$B%A%'%s%8%;%C%H$GH/@8$7$?$3$H$,J,$+$C$F$$$F!$%5!<%A$r$=$l$i$N%A%'(B
$B%s%8%;%C%H$K8BDj$7$?$H$7$F$b!$%P%0$r0z$-5/$3$7$?%A%'%s%8%;%C%H$NFCDj$K(B40
$B;~4V0J>e$+$+$k!%(B

%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}$B$O$"$J$?$N%W%m%8%'%/%H$N%j%S%8%g%sMzNr$N(B``$B%7%'%$%W(B''$B$NCN<1(B
$B$r!$%5!<%A$9$Y$-%A%'%s%8%;%C%H?t$N(B\emph{$BBP?t(B}$B$KHfNc$7$?;~4V$G%5!<%A$9$k$?(B
$B$a$K;H$&!%!JFsJ,C5:w$r9T$&!%!K$3$N%"%W%m!<%A$K$h$C$F(B10000$B%A%'%s%8%;%C%H(B
$B$N%5!<%A$O!$3F!9$N%5!<%A$,(B10$BJ,$+$+$C$?$H$7$F$b!$%F%9%H?t$O(B14$B$G(B3$B;~4V0J2<$G(B
$B=*N;$9$k!%:G8e$N(B100$B$N%A%'%s%8%;%C%H$K8B$C$F9T$C$?$H$9$k$H!$$*$h$=(B7$B2s$N(B
$B%F%9%H$G(B1$B;~4VDxEY$G=*N;$9$k!%(B

%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}$B%3%^%s%I$O!$(BMercurial$B%W%m%8%'%/%H$N%j%S%8%g%sMzNr$,;^J,$+$l(B
$B$7$,$A$J@-<A$r;}$D$3$H$rG0F,$K$*$$$F@_7W$5$l$F$*$j!$%j%]%8%H%j$K%V%i%s%A!$(B
$B%^!<%8!$J#?t$N%X%C%I$,$"$C$F$bLdBj$J$/<h$j07$($k!%0l2s$N(Bprobe$B$GMzNr$NCf(B
$B$N$"$kJ,;^A4$F$r4"$k$3$H$,$G$-$k$?$a!$6K$a$F8zN(E*$KF0:n$9$k!%(B

%\subsection{Using the \hgcmd{bisect} command}
\subsection{\hgcmd{bisect}$B%3%^%s%I$r;H$&(B}

%Here's an example of \hgcmd{bisect} in action.
\hgcmd{bisect}$B$NF0:n$rNc$G<($9!%(B

%\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}
  $B%P!<%8%g%s(B0.9.5$B0JA0$N(BMercurial$B$G$O!$(B\hgcmd{bisect}$B$O%3%"%3%^%s%I$G$O$J(B
 $B$/!$(Bextension$B$H$7$F(BMercurial$B$KF1:-$5$l$F$$$?!%$3$N@a$O8E$$(Bextension$B$K$D(B
 $B$$$F$G$O$J$/!$%S%k%H%$%s%3%^%s%I$H$7$F$N(B\hgcmd{bisect}$B$K$D$$$F=R$Y$F$$$k!%(B
\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}

$BFHN)$7$F(B\hgcmd{bisect}$B$r;n$;$k$h$&$K%j%]%8%H%j$r:n@.$9$k!%(B
\interaction{bisect.init}
$BC1=c$J%P%0$N$"$k%W%m%8%'%/%H$r%7%_%e%l!<%H$9$k!%%P%0$O7+JV$7A`:n$N4V$K<+(B
$BL@$JJQ99$r9T$$!$FCDj$N(B1$B$D$NJQ99$r%P%0$r;}$D$H;XL>$9$k!%$3$N%k!<%W$O(B35
$B$N%A%'%s%8%;%C%H$r:n$j!$3F!9!$(B1$B$D$N%U%!%$%k$r%j%]%8%H%j$KDI2C$9$k!%%P%0(B
$B$O(B``i have a gub''$B$H$$$&J8;zNs$r;}$D%U%!%$%k$GI=8=$9$k!%(B
\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}

$B<!$K(B\hgcmd{bisect}$B$N;H$$J}$r@bL@$7$?$$!%(BMercurial$B$N%S%k%H%$%s$N%X%k%W$,(B
$B;H$($k!%(B
\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}$B%3%^%s%I$OCJ3,$rF'$s$GF0:n$9$k!%3FCJ3,$O0J2<$N$h$&$K?J$`!%(B
\begin{enumerate}
\item $B%P%$%J%j%F%9%H$r<B9T$9$k(B
  \begin{itemize}
   \item $B%F%9%H$,@.8y$7$?>l9g!$(B\hgcmd{bisect}$B$r0z?t(B\hgcmdargs{bisect}{good}
	$B$rIU$1$F<B9T$9$k!%(B
   \item $B%F%9%H$,<:GT$7$?>l9g$O(B\hgcmdargs{bisect}{--bad}$B%3%^%s%I$r<B9T$9(B
	 $B$k!%(B
  \end{itemize}
 \item $B%3%^%s%I$O0z?t$GEO$5$l$?>pJs$r;H$C$F<!$K$I$N%A%'%s%8%;%C%H$r%F%9(B
      $B%H$9$Y$-$+7hDj$9$k!%(B
 \item $B%3%^%s%I$O%o!<%-%s%0%G%#%l%/%H%j$r$=$N%A%'%s%8%;%C%H$K99?7$9$k!%(B
      $B%W%m%;%9$r:F3+$9$k!%(B
\end{enumerate}
\hgcmd{bisect}$B$N%W%m%;%9$O!$%F%9%H$,@.8y$+$i<:GT$XJQ2=$7$?%A%'%s%8%;%C%H(B
$B$rFCDj$G$-$k$H=*N;$9$k!%(B

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

$B%5!<%A$r;O$a$k$K$O(B\hgcmdargs{bisect}{--reset}$B$r<B9T$9$k!%(B
\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''.

$B$3$N%1!<%9$G$O!$%P%$%J%j%F%9%H$OC1=c$G!$%j%]%8%H%jFb$K(B``i have a gub''$B$r(B
$B4^$`%U%!%$%k$,$"$k$+$I$&$+$r%A%'%C%/$9$k$@$1$G$"$k!%$b$7$3$l$,$"$l$P!$$=(B
$B$N%A%'%s%8%;%C%H$,%P%0$r0z$-5/$3$7$F$$$kJQ99$r4^$s$G$$$k$H$$$&$3$H$K$J$k!%(B
$B47Nc$K=>$C$F!$C5$7$F$$$k%A%'%s%8%;%C%H$r(B``bad''$B!$$=$l0J30$r(B``good''$B$H8F(B
$B$V$3$H$K$9$k!%(B

%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}

$BBgDq$N>l9g!$%o!<%-%s%0%G%#%l%/%H%j$,F14|$7$F$$$k%j%S%8%g%s!JDL>o$O(Btip$B$N(B
$B$O$:$@!K$O!$%P%0$N$"$kJQ99$K$h$C$F0z$-5/$3$5$l$?LdBj$r<($7$F$$$k$N$G!$$3(B
$B$N%j%S%8%g%s$r(B``bad''$B$H%^!<%/$9$k!%(B
\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}

$B<!$K%P%0$r(B\emph{$B4^$^$J$$(B}$B%j%S%8%g%s$r;XL>$9$k!%(B\hgcmd{bisect}$B%3%^%s%I$O(B
$B:G=i$N(B``good''$B%A%'%s%8%;%C%H$H(B``bad''$B%A%'%s%8%;%C%H$r%V%i%1%C%H$9$k!%$3(B
$B$NNc$G$O!$%j%S%8%g%s(B~10$B$O%P%0$r;}$?$J$$$HJ,$+$C$F$$$k!%!J:G=i$N(B``good''
$B%A%'%s%8%;%C%H$NA*$SJ}$K$D$$$F$O8e=R$9$k!%!K(B
\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}

$B%3%^%s%I$+$i=PNO$,$"$k$3$H$KCm0U!%(B
\begin{itemize}
 \item $B%P%0$NF~$C$?%A%'%s%8%;%C%H$rFCDj$9$k$^$G$K9MN8$9$Y$-%A%'%s%8%;%C%H(B
      $B$N8D?t$H!$I,MW$J8!::$N2s?t$rI=<($9$k!%(B
 \item $B%o!<%-%s%0%G%#%l%/%H%j$r<!$N%F%9%H$9$Y$-%A%'%s%8%;%C%H$K99?7$7!$(B
       $B$I$N%A%'%s%8%;%C%H$r%F%9%H$7$F$$$k$N$+$rI=<($9$k!%(B
\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}

$B$3$3$G%o!<%-%s%0%G%#%l%/%H%j$G%F%9%H$r9T$&$3$H$,$G$-$k!%(B\command{grep}$B%3(B
$B%^%s%I$r;H$C$F(B``bad''$B%U%!%$%k$,%o!<%-%s%0%G%#%l%/%H%j$K$"$k$+$I$&$+$r%A%'%C(B
$B%/$9$k!%$b$7B8:_$9$l$P!$%j%S%8%g%s$O(Bbad$B$G!$B8:_$7$J$1$l$P%j%S%8%g%s$O(B
good$B$H$$$&$3$H$K$J$k!%(B
\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}

$B$3$N%F%9%H$O40A4$K<+F02=$G$-$k!%%7%'%k4X?t$K$7$F$_$h$&!%(B
\interaction{bisect.search.mytest}
$B%F%9%HA4BN$r0l$D$N(B\texttt{mytest}$B%3%^%s%I$H$7$F<B9T$G$-$k$h$&$K$J$C$?!%(B
\interaction{bisect.search.step2}
$B$3$N%Q%C%/$5$l$?%F%9%H%3%^%s%I$r5/F0$9$k$@$1$G%F%9%H$,40N;$9$k!%(B
\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$B8D$N%A%'%s%8%;%C%H$,$"$k$K$b$+$+$o$i$:!$(B\hgcmd{bisect}$B%3%^%s%I$O%P%0$r(B
$B$b$?$i$7$?%A%'%s%8%;%C%H$r(B5$B2s$N%F%9%H$GH/8+$9$k$3$H$,$G$-$?!%(B
\hgcmd{bisect}$B$N%F%9%H2s?t$OC5:w$9$Y$-%A%'%s%8%;%C%H?t$,A}$($k$K=>$C$F!$(B
$BBP?tE*$KA}$($k$,!$iMDY$7C5:w$KBP$9$kM%0L@-$O!$%A%'%s%8%;%C%H$,A}2C$9$k$K(B
$B=>$C$FA}2C$9$k!%(B


%\subsection{Cleaning up after your search}
\subsection{$B%5!<%A8e$N%/%j!<%s%"%C%W(B}

%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}

$B%j%]%8%H%jFb$G(B\hgcmd{bisect}$B%3%^%s%I$r;H$$=*$C$?8e$K(B
\hgcmdargs{bisect}{reset}$B%3%^%s%I$GC5:w$K;H$C$?>pJs$r>C5n$9$k$3$H$,$G$-(B
$B$k!%%3%^%s%I$OBg$-$J%9%Z!<%9$r;H$&$o$1$G$O$J$$$N$G!$$3$N%3%^%s%I$r<B9T$9(B
$B$k$N$rK:$l$F$bFC$KLdBj$O$J$$!%$7$+$7(B\hgcmd{bisect}$B$O(B
\hgcmdargs{bisect}{reset}$B$,<B9T$5$l$k$^$G!$$=$N%j%]%8%H%jFb$G?7$?$JC5:w(B
$B$r;O$a$k$3$H$O$G$-$J$$!%(B
\interaction{bisect.search.reset}

%\section{Tips for finding bugs effectively}
\section{$B8zN(E*$J%P%0$NH/8+K!(B}

%\subsection{Give consistent input}
\subsection{$B@5$7$$F~NO$r9T$&(B}

%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}$B%3%^%s%I$O3F%F%9%H$G@5$7$/7k2L$rF~NO$9$k$3$H$,I,MW$G$"$k!%(B
$B$b$7%F%9%H$K@.8y$7$?$N$K<:GT$HF~NO$9$l$P!$L7=b$,@8$8$&$k!%F~NO$NCf$KL7=b(B
$B$,$"$k$3$H$,J,$+$l$P!$%3%^%s%I$OFCDj$N%A%'%s%8%;%C%H$r(Bgood$B$+$D(Bbad$B$HI=<($9(B
$B$k!%$7$+$7L7=b$r40`z$K8+$D$1=P$9$3$H$O:$Fq$G!$8m$C$?%A%'%s%8%;%C%H$r%P%0(B
$B$N5/8;$HJs9p$9$k2DG=@-$,9b$$!%(B

%\subsection{Automate as much as possible}
\subsection{$B$G$-$k8B$j<+F02=$9$k(B}

%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}$B%3%^%s%I$r;H$$$O$8$a$?;~!$?t2s!$%3%^%s%I%i%$%s$+$i<j$G%F%9(B
$B%H$r<B9T$7$?!%$3$NJ}K!$OE,$7$?J}K!$G$O$J$$!%?t2s$N%F%9%H$N8e$G!$:G=*E*$J(B
$B7k2L$rF@$k$?$a$K%5!<%A$r$d$j$J$*$5$J$1$l$P$J$i$J$$$3$H$K5$$E$/$3$H$,2?EY(B
$B$+$"$C$?!%(B

%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}$B%3%^%s%I$r<j$G<B9T$7$F$$$?;~$N:G=i$NLdBj$O!$>.$5$J%j%]%8%H(B
$B%j$G$NC1=c$J%5!<%A$G$b5/$3$C$?!%$b$7LdBj$,$b$C$HNt0-$G!$(B\hgcmd{bisect}$B$,(B
$B<B9T$7$J$1$l$P$J$i$J$$%F%9%H$N?t$,A}$($l$P!$%*%Z%l!<%?$N%(%i!<$,5/$3$k2D(B
$BG=@-$O$:$C$H9b$/$J$k!%0lEY%F%9%H$r<+F02=$7$F$+$i$O!$$:$C$H$h$$7k2L$,F@$i(B
$B$l$k$h$&$K$J$C$?!%(B

%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.

$B%F%9%H$r<+F02=$9$k%-!<$O(B2$B$D$"$k!%(B
\begin{itemize}
 \item $B>o$KF1$8C{8u$r%F%9%H$9$k!%$=$7$F(B
 \item $B>o$K(B\hgcmd{bisect}$B%3%^%s%I$K0l4S$7$?F~NO$r9T$&!%(B
\end{itemize}
$B>e$N%A%e!<%H%j%"%kNc$G$O(B\command{grep}$B%3%^%s%I$,C{8u$r%F%9%H$7$F$*$j!$(B
\texttt{if}$BJ8$,$3$N%A%'%C%/$N7k2L$r<h$j!$>o$KF1$8F~NO$,(B\hgcmd{bisect}$B%3(B
$B%^%s%I$K$J$5$l$k$h$&$K$J$C$F$$$?!%(B\texttt{mytest}$B4X?t$O!$:F8=2DG=$JJ}K!(B
$B$G!$$3$l$i$r7k$S$D$1!$$3$3$N%F%9%H$,0lMM$G0l4S$9$k$h$&$K$J$C$F$$$?!%(B


%\subsection{Check your results}
\subsection{$B7k2L$r%A%'%C%/$9$k(B}

%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}$B%5!<%A$N=PNO$O!$%f!<%6$NF~NO$,@5$7$$>l9g$K8B$C$F@5$7$$$N$G!$(B
$B%3%^%s%I$,Js9p$9$k%A%'%s%8%;%C%H$r@dBP$K@5$7$$$H9M$($F$O$$$1$J$$!%Js9p$N(B
$B%/%m%9%A%'%C%/$r9T$&C1=c$JJ}K!$O!$0J2<$N%A%'%s%8%;%C%H$KBP$7$F!$<jF0$G%F(B
$B%9%H$r9T$&$3$H$G$"$k!%(B
\begin{itemize}
 \item $B:G=i$N(Bbad$B%j%S%8%g%s$H$7$FJs9p$5$l$k%A%'%s%8%;%C%H!%$3$l$K$D$$$F%F(B
       $B%9%H$O(Bbad$B$H$J$kH&$G$"$k(B
 \item $B$=$N%A%'%s%8%;%C%H$N?F!J%^!<%8$5$l$F$$$k$J$iN>J}$N?F!K!%%F%9%H$O(B
       good$B$K$J$kH&$G$"$k(B
 \item $B:G=i$N(Bbad$B%j%S%8%g%s$H$7$FJs9p$5$l$k%A%'%s%8%;%C%H$N;R!%%F%9%H$O(B
       bad$B$H$J$kH&$G$"$k(B
\end{itemize}

%\subsection{Beware interference between bugs}
\subsection{$B%P%0F1;N$NAj8_43>D$KN10U$9$k(B}

%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.

$B0l$D$N%P%0$KBP$9$k%5!<%A$,$=$NB>$N%P%0$NB8:_$G:.Mp$5$;$i$l$k$3$H$,M-$jF@(B
$B$k!%Nc$($P%=%U%H%&%'%"$,%j%S%8%g%s(B100$B$G%/%i%C%7%e$7!$%j%S%8%g%s(B50$B$GF0:n(B
$B$7$?$H$9$k!%$"$J$?$K$OL$CN$@$,!$C/$+JL$N?M$,%j%S%8%g%s(B60$B$GB>$N%/%i%C%7%e(B
$B$9$k%P%0$r;}$A9~$_!$%j%S%8%g%s(B80$B$G=$@5$7$?$H$9$k!%$3$l$O7k2L$rJ#?t$NJ}8~(B
$B$XY`6J$2F@$k!%(B

%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}.

$B$3$NJL$N%P%0$,DI$$$+$1$F$$$k%P%0$r40A4$K%^%9%/$7$F$7$^$&$3$H$bM-$jF@$k!%(B
$BDI$$$+$1$F$$$k%P%0$,L@$i$+$K$J$kA0$K$3$l$,5/$-$k$3$H$bM-$jF@$k!%B>$N%P%0(B
$B$,KI$.@Z$l$J$$$J$i!$%P%0$,FCDj$N%A%'%s%8%;%C%H$K4^$^$l$k$H8@$&$3$H$b$G$-(B
$B$J$$!%(B\hgcmd{bisect}$B%3%^%s%I$OD>@\$"$J$?$r=u$1$k$3$H$,$G$-$J$$!%$=$NBe$o(B
$B$j!$$"$k%A%'%s%8%;%C%H$r(B\hgcmdargs{bisect}{--skip}$B$K$h$C$FL$%F%9%H$H%^!<(B
$B%/$9$k$3$H$,$G$-$k!%(B


%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}.

$B%P%0$N%F%9%H$,==J,$K>\:Y$G$J$+$C$?>l9g!$JL$NLdBj$,5/$3$jF@$k!%%W%m%0%i%`(B
$B$,%/%i%C%7%e$9$k$+$I$&$+$r%A%'%C%/$7$F$$$k;~!$DI@W$7$F$$$k%/%i%C%7%e%P%0(B
$B$H!$$=$l$H$OL54X78$J%/%i%C%7%e%P%0$,:.:_$F$$$k$H$3$l$i$OF1$8$K8+$($F$7$^(B
$B$$!$7k2LE*$K%A%'%C%/$r%^%9%/$7$F$7$^$$!$(B\hgcmd{bisect}$B$r%_%9%j!<%I$9$k!%(B


%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}$B$,M-8z$JJL$NNc$H$7$F!$%S%k%IITG=$K$J$kJQ99$,(B
$B%A%'%C%/%$%s$5$l$?%j%S%8%g%s$,$"$j!$$3$l$rHt$P$5$J$1$l$P%F%9%H$,$G$-$J$$(B
$B$h$&$J>u67$,$"$k!%(B

%\subsection{Bracket your search lazily}
\subsection{$BC5:w$rBUBF$K%V%i%1%C%H$9$k(B}

%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''.

$B:G=i$N(Bgood$B$H(Bbad$B%A%'%s%8%;%C%H$NAH$rA*$S!$%5!<%AHO0O$r;XDj$9$k$N$OB?$/$N(B
$B>l9g4JC1$@$,!$<c43$N5DO@$NM>CO$,$"$k!%(B\hgcmd{bisect}$B$+$i8+$?;~!$:G?7$N%A%'(B
$B%s%8%;%C%H$O(Bbad$B$G!$8E$$%A%'%s%8%;%C%H$O(Bgood$B$H$J$k!%(B

%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).

$BE,@Z$J(Bgood$B%A%'%s%8%;%C%H$r3P$($F$$$J$$;~!$(B\hgcmd{bisect}$B$K$=$l$r;XDj$9$k(B
$B$H!$%i%s%@%`$KA*$V$h$j$b0-$$C5:w$r9T$&2DG=@-$,$"$k!%%P%0$r<($5$J$$!J$*$=(B
$B$i$/%P%0$N$"$k5!G=$,<BAu$5$l$F$$$J$$!K%A%'%s%8%;%C%H$H!$B>$NLdBj$,DI@WCf(B
$B$N%P%0$r%^%9%/$7$F$7$^$&$h$&$J%A%'%s%8%;%C%H$N$_$r>C5n$9$k$3$H$r3P$($F$*(B
$B$/$Y$-$@!%(B

%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}$B$,9T$o$J$1$l$P$J$i$J$$%F%9%H$N2s?t$O!$BP>]$H$9$k%A%'%s%8%;%C(B
$B%H$NBP?t$KHfNc$9$k$?$a!$?t%u7n$K5Z$VMzNr$NCf$N?t@i$N%A%'%s%8%;%C%H$NCf$K(B
$BBP$7$F$b>/?t$N%F%9%H$rDI2C$9$k$@$1$G:Q$`!%(B


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