Mercurial > hgbook

--- a/ja/undo.tex	Tue Feb 12 14:42:07 2008 +0900
+++ b/ja/undo.tex	Tue Feb 12 15:40:48 2008 +0900
@@ -894,67 +894,116 @@
 $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.
+%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 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.
+ \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.

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

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

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

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