changeset 314:aa132d5e2b32

completed draft translation for undo.tex.

--- a/ja/undo.tex	Sun Feb 17 22:53:01 2008 +0900
+++ b/ja/undo.tex	Mon Feb 18 03:53:20 2008 +0900
@@ -1023,199 +1023,372 @@
  $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.
+%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}
-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''.
+$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.
+%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.
+%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 You run your binary test.
+\item $B%P%$%J%j%F%9%H$r<B9T$9$k(B
   \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.
+   \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 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.
+ \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}
-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$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.
+%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''.
+%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''.
 
-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''.
+$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.)
+%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.
+%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 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.
+ \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.
+%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.
+%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}
-We can now run an entire test step with a single command,
-\texttt{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}
-A few more invocations of our canned test step command, and we're
-done.
+$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.
+%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{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}.
+%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{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}
 
-\subsection{Give consistent input}
+%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}
 
-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.
+%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
 
-\subsection{Automate as much as possible}
+%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.
 
-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<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
 
-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.
+%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.
 
-The key to automated testing is twofold:
+$B%F%9%H$r<+F02=$9$k%-!<$O(B2$B$D$"$k!%(B
 \begin{itemize}
-\item always test for the same symptom, and
-\item always feed consistent input to the \hgcmd{bisect} command.
+ \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}
-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>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{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:
+%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 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.
+ \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{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.
+%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}.
+%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}.
 
-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$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.
+%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{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''.
 
-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).
 
-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.
+%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