# HG changeset patch # User Yoshiki Yazawa # Date 1253021523 -32400 # Node ID b775f963b18c7833bbc01c1e148193350229b537 # Parent d819bc2414f4ff1537e5cb2fe5142c68363c0ae8 Clean up chapter 8, and add content propagate 7226e5e750a6 diff -r d819bc2414f4 -r b775f963b18c ja/Makefile.tex --- a/ja/Makefile.tex Thu Jul 23 18:10:58 2009 +0900 +++ b/ja/Makefile.tex Tue Sep 15 22:32:03 2009 +0900 @@ -43,6 +43,11 @@ undo-manual-merge.dot \ undo-non-tip.dot \ undo-simple.dot \ + figs/bad-merge-1.dot \ + figs/bad-merge-2.dot \ + figs/bad-merge-3.dot \ + figs/bad-merge-4.dot \ + figs/bad-merge-5.dot \ wdir.svg \ wdir-after-commit.svg \ wdir-branch.svg \ diff -r d819bc2414f4 -r b775f963b18c ja/undo.tex --- a/ja/undo.tex Thu Jul 23 18:10:58 2009 +0900 +++ b/ja/undo.tex Tue Sep 15 22:32:03 2009 +0900 @@ -164,31 +164,30 @@ %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. +%you'll have to recover from your mistake in a different way. +%If you push a changeset somewhere, then roll it back, then pull from the +%repository you pushed to, the changeset you thought you'd gotten rid of +%will simply reappear in your repository. もしあなたが他のリポジトリ（特に共有リポジトリ）に変更をプッシュしている のなら，困った事態が起こっており，別の方法でミスから復旧する必要がある． チェンジセットをどこかへプッシュした後でロールバックし，プッシュ先のリポ -ジトリから再びプルした場合，チェンジセットがローカルリポジトリに再び現れ -る． +ジトリから再びプルした場合，削除したつもりのチェンジセットがローカルリポ +ジトリに再び現れる． %(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.) +%should not expect this to work reliably. 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.) （もしロールバックしたいチェンジセットがプッシュ先のリポジトリで最新であ -り，かつ，誰もそれをプルしていないことが確実である場合は，プッシュ先のリ -ポジトリでロールバックすることが可能だが，この方法は確実ではないというこ -とを肝に命じておくべきである．この方法は直接コントロールできなかったり， -その方法を忘れてしまったリポジトリへの変更の修正には使えない．） +り，かつ，誰もそれをプルしていないことが確実な場合は，プッシュ先のリポジ +トリでロールバックすることが可能である．しかしこの方法には確実性がないと +いうことを肝に命じておくべきである．この方法は直接コントロールできなかっ +たり，その方法を忘れてしまったリポジトリへの変更の修正には使えない．） %\subsection{You can only roll back once} @@ -248,6 +247,26 @@ をセーブする． \interaction{daily.revert.status} +\begin{note} +%Be careful with \filename{.orig} files +\filename{.orig}ファイルに注意 + +%It's extremely unlikely that you are either using Mercurial to manage +%files with \filename{.orig} extensions or that you even care about the +%contents of such files. Just in case, though, it's useful to remember +%that \hgcmd{revert} will unconditionally overwrite an existing file with +%a \filename{.orig} extension. For instance, if you already have a file +%named \filename{foo.orig} when you revert \filename{foo}, the contents +%of \filename{foo.orig} will be clobbered. + +\filename{.orig}という拡張子を持つファイルをMercurialで管理したり，その内 +容に関心を持つことはおそらくほとんどないだろう．そうでない場合は +\hgcmd{revert}が無条件に拡張子\filename{.orig}のファイルを上書きすること +に留意すべきである．例を挙げると\filename{foo.orig}というファイルがあると +き，\filename{foo}をrevertすると\filename{foo.orig}の中身は損なわれてしま +う． +\end{note} + %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. @@ -331,75 +350,31 @@ ともない． -%\subsubsection{A slightly special case: reverting a rename} -\subsubsection{やや特殊なケース：リネームの取り消し} - -%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}した後では，少し留意しておくべき点がある．リネーム後に -\hgcmd{revert}した場合，ここで説明するように，リネームしたファイルの名前 -を指定するだけでは不十分である． -\interaction{daily.revert.rename} -\hgcmd{status}の出力から分かるように，リネーム先のファイルはもはやaddさ -れた扱いになっていない．しかしリネーム\emph{元}のファイルはまだ消去され -たままになっている．これは（少なくとも筆者にとって）非直感的だが，取り扱 -いは簡単である． -\interaction{daily.revert.rename-orig} -\hgcmd{rename}を取り消す際には，元のファイルとリネーム後のファイル -\emph{両方}を指定する必要がある． - -%(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.) - -（一方，リネームした後にリネーム先のファイルを編集し，リネームの前後のファ -イル名を指定して取り消しを行い，Mercurialがリネームの際に消去されたファ -イルを修復すると，このファイルは編集前の状態になっている．リネーム後のファ -イルへの変更がリネーム前のファイルに残るようにするには，コピーを作ってお -く必要がある．） - -%These fiddly aspects of reverting a rename arguably constitute a small -%bug in Mercurial. - -リネームを復元する時に起こる厄介ごとはおそらくMercurialのバグと言えるか -もしれない． - - %\section{Dealing with committed changes} \section{コミットされた変更の扱い} -%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 +%Consider a case where you have committed a change \emph{a}, and another +%change \emph{b} on top of it; you then realise that change \emph{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$をコミットし，ここで$a$は誤りであることに気が -ついた場合を考える．Mercurialはチェンジセット全体とチェンジセットの一部分 -を手でバックアウトするように促す． +\emph{a}をコミットした後で別の\emph{b}をコミットし，ここで\emph{a}が誤り +であることに気づいた場合を考える．Mercurialはチェンジセット全体とチェンジ +セットの一部分を手でバックアウトするように促す． %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}. +%\hgcmd{backout} command undoes the effect of a change by \emph{adding} +%to your repository's 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}. -この節を読む前に，\hgcmd{backout}コマンドは履歴に\emph{追加}することで取 -り消し操作を行うことを覚えておいて欲しい．変更や消去ではない．バグの修 -正のために役立つツールだが，変更の取り消しのために用いると破滅的な結果を -もたらす．後者の目的のためには\ref{sec:undo:aaaiiieee}を参照のこと． +この節を読む前に，\hgcmd{backout}コマンドはリポジトリ履歴を新たに\emph{追 +加}することで変更による影響を取り消すことを覚えておいて欲しい．履歴の変更 +や消去ではない．\hgcmd{backout}はバグの修正のために役立つツールだが，大規 +模な影響を持つ変更を取り消すためのツールではない．後者の目的のためには +\ref{sec:undo:aaaiiieee}を参照されたい． %\subsection{Backing out a changeset} \subsection{チェンジセットのバックアウト} @@ -496,20 +471,25 @@ \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. +%illustrates, Mercurial still commits one change in this kind of +%situation (the box-shaped node is the ones that Mercurial commits +%automatically), but the revision graph now looks different. 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, but notice that it +%\emph{does not commit} the result of the merge. The repository now +%contains two heads, and the working directory is in a merge state. -図\ref{fig:undo:backout-non-tip}で示された履歴で，Mercurialは2つのコミッ -トを行っている．（図中で箱で示された節点はMercurialが自動的にコミットし -た変更である．）バックアウトプロセスの前にMercurialは，現在のワーキングディ -レクトリの親が何であるかを記憶する．そしてターゲットのチェンジセットを取 -り除き，これをチェンジセットとしてコミットする．最後にワーキングディレク -トリの前の親へマージを行い，マージの結果をコミットする． +図\ref{fig:undo:backout-non-tip}の履歴グラフで，Mercurialは1つの変更をコ +ミットしている（図中で箱で示された節点はMercurialが自動的に行ったコミット +である．）が，リビジョングラフには変化が起きている．バックアウトプロセス +の前にMercurialは，現在のワーキングディレクトリの親が何であるかを記憶す +る．そしてターゲットのチェンジセットを取り除き，これをチェンジセットとし +てコミットする．最後にMercurialはワーキングディレクトリの以前の両親にマー +ジを行うが，マージの結果を\emph{コミットしない}ことに留意されたい．この時 +点でリポジトリは2つのヘッドを持ち，ワーキングディレクトリはマージ済みの状 +態になる． \begin{figure}[htb] \centering @@ -524,9 +504,21 @@ %extra history that undoes the effect of the changeset you wanted to %back out. -最終的に，いくらかの余計な履歴を残しつつ，取り除きたかったチェンジセット -の影響を除去して，望む状態に戻すことができている． +最終的に，取り除きたかったチェンジセットの影響を除去し，履歴に除去の記録 +こそ増えているものの，望む状態に戻すことができている． +%You might wonder why Mercurial does not commit the result of the merge +%that it performed. The reason lies in Mercurial behaving +%conservatively: a merge naturally has more scope for error than simply +%undoing the effect of the tip changeset, so your work will be safest if +%you first inspect (and test!) the result of the merge, \emph{then} +%commit it. + +なぜMercurialがマージの際にコミットも行わないのか疑問に感じるかもしれな +い．Mercurialがこのような動作をする理由は，マージは単にtipチェンジセット +の効果を取り除く場合よりもエラーの原因になる要素が多く，そのため，まずマー +ジの結果を検査し，場合によってはテストも行って，その上でコミットすべきで +あるという考えで設計されているためである． %\subsubsection{Always use the \hgopt{backout}{--merge} option} \subsubsection{常に\hgopt{backout}{--merge}オプションを使う} @@ -659,10 +651,10 @@ %\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} +% 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} +% 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 @@ -678,7 +670,7 @@ \hgcmd{backout}がどのように動作するか完結に説明すると以下のようになる． \begin{enumerate} \item ワーキングディレクトリがクリーンであることを確認する．i.e.\hgcmd{status} - が空であることを確認する + が空であることを確認する． \item 現在のワーキングディレクトリの親を記憶する．このチェンジセットを \texttt{orig}と呼ぶことにする． \item ワーキングディレクトリを，バックアウトしたチェンジセットの内容に @@ -801,7 +793,7 @@ %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 +%change 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. @@ -820,13 +812,129 @@ たとすれば，使えるオプションはさらに少なくなる．Mercurialはチェンジセッ トをそのままに履歴に穴を開けるような方法を提供していない． -%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{Backing out a merge} +\subsection{マージ結果のバックアウト} + +%Since merges are often complicated, it is not unheard of for a merge to +%be mangled badly, but committed erroneously. Mercurial provides an +%important safeguard against bad merges by refusing to commit unresolved +%files, but human ingenuity guarantees that it is still possible to mess +%a merge up and commit it. + +マージは複雑なことも多く，ひどく錯綜したり，誤ってコミットされる場合もあ +る． Mercurialには，未リゾルブのファイルのコミットを拒否することで誤った +マージからリポジトリを守る手立てがある．しかしそれでもマージ状態を混乱さ +せ，それをコミットすることが可能である． + +%Given a bad merge that has been committed, usually the best way to +%approach it is to simply try to repair the damage by hand. A complete +%disaster that cannot be easily fixed up by hand ought to be very rare, +%but the \hgcmd{backout} command may help in making the cleanup +%easier. It offers a \hgopt{backout}{--parent} option, which lets you +%specify which parent to revert to when backing out a merge. + +間違ったマージがコミットされた場合，通常は手動で修復を行うのが最も良いア +プローチである．手動で修復できないような大惨事は滅多にない +が，\hgcmd{backout}コマンドが修復の助けになるかもしれな +い．\hgopt{backout}{--parent}オプションを使うと，どの親からマージのバック +アウトを行うかを指定できる． + +\begin{figure}[htb] + \centering + \grafix{figs/bad-merge-1} + % +% \caption{A bad merge} + \caption{間違ったマージ} + \label{fig:undo:bad-merge-1} +\end{figure} + +%Suppose we have a revision graph like that in +%\ref{fig:undo:bad-merge-1}. What we'd like is to \emph{redo} the merge +%of revisions 2 and 3. + +図\ref{fig:undo:bad-merge-1}のようなリビジョングラフになっているとする． +ここでリビジョン2と3のマージを再び行いたい． + +%One way to do so would be as follows. + +その方法の一つは以下のようになる． + +\begin{enumerate} +% \item Call \hgopt{backout}{--rev=4 --parent=2}. This tells +% \hgcmd{backout} to back out revision 4, which is the bad merge, +% and to when deciding which revision to prefer, to choose parent +% 2, one of the parents of the merge. The effect can be seen in +% \ref{fig:undo:bad-merge-2}. + \item \hgopt{backout}{--rev=4 --parent=2}を実行する．\hgcmd{backout}は + 問題のあるマージであるリビジョン4をバックアウトし，戻すべきリビジョ + ンを決める際に，両方の親のうち，リビジョン2を選ぶ．結果を図 + \ref{fig:undo:bad-merge-2}に示す． -XXX 追記の必要性あり．\texttt{examples}ディレクトリ内の -\texttt{hg-replay}スクリプトは機能するが，チェンジセットのマージを扱わな -い．重要な制限である． + \begin{figure}[htb] + \centering + \grafix{figs/bad-merge-2} + % + % \caption{Backing out the merge, favoring one parent} + \caption{マージをバックアウトし，親の一方を選ぶ} + \label{fig:undo:bad-merge-2} + \end{figure} + +% \item Call \hgopt{backout}{--rev=4 --parent=3}. This tells +% \hgcmd{backout} to back out revision 4 again, but this time to +% choose parent 3, the other parent of the merge. The result is +% visible in \ref{fig:undo:bad-merge-3}, in which the repository +% now contains three heads. + + \item \hgopt{backout}{--rev=4 --parent=3}を実行する．\hgcmd{backout}はや + はりリビジョン4をバックアウトするが，今回はマージの親のうちリビジョ + ン3を選ぶ．結果は図\ref{fig:undo:bad-merge-3}のようになり，リポジ + トリにはヘッドが3つできる． + + \begin{figure}[htb] + \centering + \grafix{figs/bad-merge-3} + % + % \caption{Backing out the merge, favoring the other parent} +% \caption{Backing out the merge, favoring the other parent} + \caption{マージをバックアウトし，もう一方の親を選ぶ} + \label{fig:undo:bad-merge-3} + \end{figure} + + +% \item Redo the bad merge by merging the two backout heads, +%which reduces the number of heads in the repository to +%two, as can be seen in \ref{fig:undo:bad-merge-4}. + + \item 問題のあったマージを，バックアウトの結果生じた2つのヘッドの間で再 + び行う．これにより，図\ref{fig:undo:bad-merge-4}のようにリポジトリ + 内のヘッドは2つになる． + + \begin{figure}[htb] + \centering + \grafix{figs/bad-merge-4} + % +% \caption{Merging the backouts} + \caption{バックアウト結果をマージする} + \label{fig:undo:bad-merge-4} + \end{figure} + +% \item Merge with the commit that was made after the bad merge, as shown +% in \ref{fig:undo:bad-merge-5}. + + \item 図\ref{fig:undo:bad-merge-5}のように，間違ったマージの後に行われ + たコミットとマージする． + + \begin{figure}[htb] + \centering + \grafix{figs/bad-merge-5} + % + % \caption{Merging the backouts} + \caption{バックアウトのマージ} + \label{fig:undo:bad-merge-5} + \end{figure} + +\end{enumerate} %\subsection{Protect yourself from ``escaped'' changes} @@ -853,16 +961,98 @@ 中央リポジトリの上で，変更到着にフックを設定する（\ref{chap:hook}を参照） ことで，ある種の誤ったチェンジセットが中央リポジトリにコミットされるのを -自動的に防ぐことができる．そのような設定を行うことで，ある種の誤ったチェ -ンジセットは中央リポジトリに波及することができず，死滅していく傾向があ -る．好都合なことに，死滅は陽に介入する必要なく起きる。 +自動的に防ぐことができる．設定を行うことで，ある種の誤ったチェンジセット +は中央リポジトリに波及することができず死滅していく．好都合なことに，死滅 +は陽に介入する必要なく起きる。 %For instance, an incoming change hook that verifies that a changeset %will actually compile can prevent people from inadvertantly ``breaking %the build''. 例えば，チェンジセットを実際にコンパイルする変更到着フックは，不注意によ -るビルド不能を防ぐことができる． +ってビルド不能となることを防ぐ効果がある． + + +%\subsection{What to do about sensitive changes that escape} +\subsection{個人情報を含むチェンジセットの漏洩} + +%Even a carefully run project can suffer an unfortunate event such as the +%committing and uncontrolled propagation of a file that contains +%important passwords. + +プロジェクトを注意深く運営していても，時として重要なパスワードの含まれた +ファイルのコミットや伝播が生じることがある． + +%If something like this happens to you, and the information that gets +%accidentally propagated is truly sensitive, your first step should be to +%mitigate the effect of the leak without trying to control the leak +%itself. If you are not 100\% certain that you know exactly who could +%have seen the changes, you should immediately change passwords, cancel +%credit cards, or find some other way to make sure that the information +%that has leaked is no longer useful. In other words, assume that the +%change has propagated far and wide, and that there's nothing more you +%can do. + +漏洩が起き，伝播した情報が極めて重要な場合，まずすべきことは漏洩自体をコ +ントロールしようとするのではなく，漏洩による影響を免れるようにすることで +ある．誰がこの情報を見たのか100\%明白でない場合は，すぐにパスワードを変更 +し，場合によってはクレジットカードを解約したり，漏洩した情報が無効になる +ように可能な手を打つべきである．別の言い方をすれば，情報はすでに大きな範 +囲に広まっており，漏洩した情報自体についてはなす術がないと仮定すべきであ +る． + +%You might hope that there would be mechanisms you could use to either +%figure out who has seen a change or to erase the change permanently +%everywhere, but there are good reasons why these are not possible. + +変更を発見した人を特定したり，あらゆる場所で変更を永久的に変更するメカニ +ズムが備わっているのではないかと期待する向きもあるだろうが，これが次のよ +うな理由で不可能である． + +%Mercurial does not provide an audit trail of who has pulled changes from +%a repository, because it is usually either impossible to record such +%information or trivial to spoof it. In a multi-user or networked +%environment, you should thus be extremely skeptical of yourself if you +%think that you have identified every place that a sensitive changeset +%has propagated to. Don't forget that people can and will send bundles +%by email, have their backup software save data offsite, carry +%repositories on USB sticks, and find other completely innocent ways to +%confound your attempts to track down every copy of a problematic change. + +Mercurialは，リポジトリから誰が変更をプルしたか追跡する機構を持たない．な +ぜならそのような情報を記録することは不可能であるか簡単に偽れるからであ +る．従って，マルチユーザ環境やネットワーク環境では，個人情報を含むチェン +ジセットが伝播した範囲を特定できると考えるべきではない．問題のあるチェン +ジセットを追跡しようとしたところで，チェンジセットを入手した人々は， +\begin{itemize} + \item バンドルを電子メールで送信する + \item サイト外にデータを保存できるバックアップソフトウェアを用いる + \item USBメモリにリポジトリを保存する + \item それ以外の予期しない方法を用いる +\end{itemize} +などの方法でいくらでも追跡を欺くことが可能だということを覚えておくべきだ． + +%Mercurial also does not provide a way to make a file or changeset +%completely disappear from history, because there is no way to enforce +%its disappearance; someone could easily modify their copy of Mercurial +%to ignore such directives. In addition, even if Mercurial provided such +%a capability, someone who simply hadn't pulled a ``make this file +%disappear'' changeset wouldn't be affected by it, nor would web crawlers +%visiting at the wrong time, disk backups, or other mechanisms. Indeed, +%no distributed revision control system can make data reliably +%vanish. Providing the illusion of such control could easily give a false +%sense of security, and be worse than not providing it at all. + +Mercurialはファイルやチェンジセットを履歴から完全に消し去る機能を提供しな +い．これは消去を強制することが不可能であることによる．仮にそのような指示 +を実装したとしても，Mercurialを改造して指示を無視するようにすることは容易 +である．また，Mercurialがそのような機能を提供したとして，``このファイルを +消せ''というチェンジセットをプルしていないユーザやタイミング悪くサイトを +訪問したサーチエンジンのクローラー，ディスクバックアップその他には何も影 +響を及ぼさない．実際のところ，分散リビジョンコントロールシステムで信頼性 +のあるデータ消滅機能を提供しているものはない．このような制御が可能だとし +ても，これは容易にセキュリティ上の脅威になり，制御機能が一切ない場合より +も深刻な状態を引き起こす． %\section{Finding the source of a bug} \section{バグの原因を見つける} @@ -980,17 +1170,19 @@ %to check (the kind of search it performs is called a dichotomic %search). +\hgcmd{bisect}はプロジェクトのリビジョン履歴の``形状''の情報を，サーチす +べきチェンジセット数の\emph{対数}に比例した時間でサーチするために使 +う．（二分探索を行う．） + %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}はあなたのプロジェクトのリビジョン履歴の``シェイプ''の知識 -を，サーチすべきチェンジセット数の\emph{対数}に比例した時間でサーチするた -めに使う．（二分探索を行う．）このアプローチによって10000チェンジセット -のサーチは，各々のサーチが10分かかったとしても，テスト数は14で3時間以下で -終了する．最後の100のチェンジセットに限って行ったとすると，およそ7回の -テストで1時間程度で終了する． +このアプローチにより，10000のチェンジセットに対するサーチは，サーチ一回あ +たり10分かかったとしても3時間以下で終了する．テスト回数は14回となる．最後 +の100のチェンジセットに限定するならば，テストはおよそ1時間程度で終了し， +テスト回数は7回となる． %The \hgcmd{bisect} command is aware of the ``branchy'' nature of a %Mercurial project's revision history, so it has no problems dealing @@ -1053,7 +1245,7 @@ %\item You run your binary test. % \begin{itemize} % \item If the test succeeded, you tell \hgcmd{bisect} by running the -% \hgcmdargs{bisect}{good} command. +% \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 @@ -1069,7 +1261,7 @@ \begin{enumerate} \item バイナリテストを実行する \begin{itemize} - \item テストが成功した場合，\hgcmd{bisect}を引数\hgcmdargs{bisect}{good} + \item テストが成功した場合，\hgcmd{bisect}を引数\hgcmdargs{bisect}{--good} を付けて実行する． \item テストが失敗した場合は\hgcmdargs{bisect}{--bad}コマンドを実行す る． @@ -1187,18 +1379,18 @@ \subsection{サーチ後のクリーンアップ} %When you're finished using the \hgcmd{bisect} command in a -%repository, you can use the \hgcmdargs{bisect}{reset} command to drop +%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}. +%that repository until you do a \hgcmdargs{bisect}{--reset}. %\interaction{bisect.search.reset} リポジトリ内で\hgcmd{bisect}コマンドを使い終った後に -\hgcmdargs{bisect}{reset}コマンドで探索に使った情報を消去することができ +\hgcmdargs{bisect}{--reset}コマンドで探索に使った情報を消去することができ る．コマンドは大きなスペースを使うわけではないので，このコマンドを実行す るのを忘れても特に問題はない．しかし\hgcmd{bisect}は -\hgcmdargs{bisect}{reset}が実行されるまで，そのリポジトリ内で新たな探索 +\hgcmdargs{bisect}{--reset}が実行されるまで，そのリポジトリ内で新たな探索 を始めることはできない． \interaction{bisect.search.reset} @@ -1331,7 +1523,6 @@ り，あるチェンジセットを\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 @@ -1342,7 +1533,6 @@ と，それとは無関係なクラッシュバグが混在ているとこれらは同じに見えてしま い，結果的にチェックをマスクしてしまい，\hgcmd{bisect}をミスリードする． - %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 @@ -1387,7 +1577,7 @@ 対しても少数のテストを追加するだけで済む． -%%% Local Variables: +%%% Local Variables: %%% mode: yatex %%% TeX-master: "00book" -%%% End: +%%% End: