# HG changeset patch # User Yoshiki Yazawa # Date 1202798448 -32400 # Node ID 593e912d6a5355e320b0c0c748d6093c868a774e # Parent dd775100013d1ffa9eae54feff380da5cd943ec5 more undo.tex diff -r dd775100013d -r 593e912d6a53 ja/undo.tex --- 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 @@ 方法は知っている．\hgcmd{bisect}コマンドは，テストによってバグを引き起こ したチェンジセットを特定する． -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} + +以下はこのコマンドをどのように適用できるのか理解を助けるシナリオである． \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 バグが起きていなかった最も新しいバージョンを覚えているが，どのバー + ジョンでバグが混入したか分からない．ここでバイナリテストを行ない， + バグの存在を調べる． + \item バグを大急ぎで修正し，あなたのチームのバグデータベースをクローズ + する．バグデータベースはどこでバグが修正されたかのチェンジセット + のIDを必要とするが，あなたはどのチェンジセットで修正されたか記憶 + していない．ここでまたバグの存在をバイナリテストする． + \item あなたのソフトウェアは正しく動いたが，以前測定した時よりも15\%遅 + くなっていた．あなたはどのチェンジセットがこの性能劣化をもたらし + たのか知りたい．この場合，バイナリテストで速度を測定する． + \item 出荷するプロジェクトのコンポーネントサイズが最近爆発的に増えた． + あなたはプロジェクトのビルドの方法になんらかの変化が起きたのでは + ないかと疑っている． \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. +この例から，\hgcmd{bisect}コマンドはバグのありかを探すのに役立つのではな +いことが分かるだろう．このコマンドはバイナリテストを行ない得るリポジトリ +で起きた（単純にツリーをテキストサーチしたのでは発見できない）変化全てを +知るのに使うことができる． -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''. + +ここでサーチのどのパートがあなたの責任に属し，どのパートがMercurialに属す +るのか明確にするために少しばかり用語を導入する．\emph{test}は\emph{あな +た}が\hgcmd{bisect}を実行する時に選んだチェンジセットである． +\emph{probe}は\hgcmd{bisect}がリビジョンが良いか判定するリビジョンである． +``bisect''という単語を``\hgcmd{bisect}コマンドを使ってサーチする''という +ことの同義語として名詞と動詞両方で用いる． + +%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. +サーチプロセスを自動化するたんん淳和方法は，全てのチェンジセットをprobe +することである．しかしこれは殆んどスケールしない．一つのチェンジセットの +チェックに10分かかり，リポジトリにチェンジセットが10000あったとしたら，虱 +潰しのアプローチはバグを発生させたチェンジセットの特定に平均で35日かかる． +バグが最後の500チェンジセットで発生したことが分かっていて，サーチをそれら +のチェンジセットに限定したとしても，バグを引き起こしたチェンジセットの特 +定に40時間以上かかる． + +%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}はあなたのプロジェクトのリビジョン履歴の``シェイプ''の知識 +を，サーチすべきチェンジセット数の\emph{対数}に比例した時間でサーチするた +めに使う．（二分検索を行なう．）このアプローチによって10000チェンジセット +のサーチは，各々のサーチが10分かかったとしても，テスト数は14で3時間以下で +終了する．最後の100のチェンジセットに限って行なったとすると，およそ7回の +テストで1時間程度で終了する． + +%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}コマンドは，Mercurialプロジェクトのリビジョン履歴が枝分かれ +しがちな性質を持つことを念頭において設計されており，リポジトリにブランチ， +マージ，複数のヘッドがあっても問題なく取り扱える．一回のprobeで履歴の中 +のある分枝全てを刈ることができるため，極めて効率的に動作する． \subsection{Using the \hgcmd{bisect} command}