comparison ja/undo.tex @ 307:bb4c3994cec7

more undo.tex

306:62ea8107a73b

$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{$B$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.

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.

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

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

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.

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
changeefrom \emph{every} one of those repositories.  This is, of
course, not a satisfactory solution: if you miss even a single
repository while you're expunging, the change is still ``in the
wild'', and could propagate further.

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

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.

\subsection{Protect yourself from ``escaped'' changes}

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

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

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

\section{Finding the source of a bug}
\label{sec:undo:bisect}

While it's all very well to be able to back out a changeset that

307:bb4c3994cec7

$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}
\label{sec:undo:bisect}

While it's all very well to be able to back out a changeset that