Mercurial > hgbook
view ja/undo.tex @ 776:019040fbf5f5
merged to upstream: phase 1
| author | Yoshiki Yazawa <yaz@honeyplanet.jp> |
|---|---|
| date | Tue, 21 Apr 2009 00:36:40 +0900 |
| parents | 32d33b238b7e |
| children | 8a3041e6f3cb |
line wrap: on
line source
%\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$J$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$J$&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!$==J,Cm0U$;$:!$$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$7$+$7(BMercurial$B$O%W%k85$N(BURL$B$H5?$$$r;}(B $B$D$K==J,$J5pBg$JJQ99$rI=<($9$k$?$a!$B(:B$K5$$E$/2DG=@-$,9b$$!%(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%j$J$$$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$J$&!%(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$J$$!$(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$$E(B $B$/$$$?>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$J$&$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$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$J$&$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$J$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$J$$!$%^!<%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$J$&!%$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$J$$!$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(Bdiff$B$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$J$&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$J$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!<%+(B $B%k%3%T!<$NJQ99$r<h$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$O0U?^$7$?$h$&$J7k2L$K$O$J$i$J$$!%JQ99$O0MA3$H$7$F(B $B%j%b!<%H$N%j%]%8%H%j$K$O$=$s$6$$$7$F$*$j!$<!$K%W%k$7$?;~$K$O%m!<%+%k%j%](B $B%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$K3H$,$jF@$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$_$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!%(B $B$=$N$h$&$J@_Dj$r9T$&$3$H$G!$$"$k<o$N8m$C$?%A%'%s%8%;%C%H$O%;%s%H%i%k%j%](B $B%8%H%j$KGH5Z$9$k$3$H$,$G$-$:!$;`LG$7$F$$$/798~$,$"$k!%$5$i$KNI$$$3$H$H$7(B $B$F$O!$$3$l$OL@<(E*$K2pF~$;$:$KH/@8$5$;$k$3$H$,$G$-$k$3$H$,$"$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$J$$!$(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$O%P%0$N$"$j$+$rC5$9$N$KLrN)$D$N$G$O$J(B $B$$$3$H$,J,$+$k$@$m$&!%$3$N%3%^%s%I$O%P%$%J%j%F%9%H$r9T$J$$F@$k%j%]%8%H%j(B $B$G5/$-$?!JC1=c$K%D%j!<$r%F%-%9%H%5!<%A$7$?$N$G$OH/8+$G$-$J$$!KJQ2=A4$F$r(B $BCN$k$N$K;H$&$3$H$,$G$-$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$k$?$s$s=_OBJ}K!$O!$A4$F$N%A%'%s%8%;%C%H$r(Bprobe $B$9$k$3$H$G$"$k!%$7$+$7$3$l$OKX$s$I%9%1!<%k$7$J$$!%0l$D$N%A%'%s%8%;%C%H$N(B $B%A%'%C%/$K(B10$BJ,$+$+$j!$%j%]%8%H%j$K%A%'%s%8%;%C%H$,(B10000$B$"$C$?$H$7$?$i!$iM(B $BDY$7$N%"%W%m!<%A$O%P%0$rH/@8$5$;$?%A%'%s%8%;%C%H$NFCDj$KJ?6Q$G(B35$BF|$+$+$k!%(B $B%P%0$,:G8e$N(B500$B%A%'%s%8%;%C%H$GH/@8$7$?$3$H$,J,$+$C$F$$$F!$%5!<%A$r$=$l$i(B $B$N%A%'%s%8%;%C%H$K8BDj$7$?$H$7$F$b!$%P%0$r0z$-5/$3$7$?%A%'%s%8%;%C%H$NFC(B $BDj$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,8!:w$r9T$J$&!%!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$J$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{$B0l4S$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$k$P!$ITDj$J>uBV$r8!CN$9$k$+$b$7$l$J(B $B$$!%F~NO$NCf$GITDj$rFCDj$G$-$l$P!$%3%^%s%I$OFCDj$N%A%'%s%8%;%C%H$,(Bgood$B$+(B $B$D(Bbad$B$G$"$k$HI=<($9$k!%$7$+$740`z$K$3$l$r9T$&$3$H$OIT2DG=$G!$4V0c$C$?%A%'(B $B%s%8%;%C%H$r%P%0$N860x$@$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$N;HMQ$,M-MQ$J$b$&0l$DJL$N>u67$O!$C/$+$,%S%k%I(B $B$G$-$J$/$J$k$h$&$JJQ99$r%A%'%C%/%$%s$7$?$?$a$K!$;n$=$&$H$7$F$$$k%j%S%8%g(B $B%s$,%S%k%I$G$-$:!$$=$N%j%S%8%g%s$r%F%9%H$G$-$J$$$h$&$J>l9g$G$"$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: