# HG changeset patch # User Yoshiki Yazawa # Date 1215878462 -32400 # Node ID f3f56da2e650b676d87e9d20d918cbae387e433d # Parent dfa9910e2a2ee341413a57b7c6c1ea46a9a4f550 more mq.tex diff -r dfa9910e2a2e -r f3f56da2e650 ja/mq.tex --- a/ja/mq.tex Wed Jul 09 01:41:17 2008 +0900 +++ b/ja/mq.tex Sun Jul 13 01:01:02 2008 +0900 @@ -968,122 +968,192 @@ %\subsection{Beware the fuzz} \subsection{曖昧な点について} -While applying a hunk at an offset, or with a fuzz factor, will often -be completely successful, these inexact techniques naturally leave -open the possibility of corrupting the patched file. The most common -cases typically involve applying a patch twice, or at an incorrect -location in the file. +%While applying a hunk at an offset, or with a fuzz factor, will often +%be completely successful, these inexact techniques naturally leave +%open the possibility of corrupting the patched file. The most common +%cases typically involve applying a patch twice, or at an incorrect +%location in the file. If \command{patch} or \hgxcmd{mq}{qpush} ever +%mentions an offset or fuzz factor, you should make sure that the +%modified files are correct afterwards. -If \command{patch} or \hgxcmd{mq}{qpush} ever -mentions an offset or fuzz factor, you should make sure that the -modified files are correct afterwards. - -あるオフセットやfuzz factorの位置へのhunkの適用は多くの場合全く問題なく成 -功するが，不正確なマッチを用いた場合，パッチを適用したファイルを壊してい -る可能性が残る． +あるオフセットやfuzz factorの位置へのhunkの適用は，多くの場合問題なく成功 +するが，不正確なマッチを用いた場合，パッチを適用したファイルを壊している +可能性が残る．最もよくあるのは，パッチを二度適用したり，ファイルの間違っ +た場所に適用してしまうことだ．\command{patch}または\hgxcmd{mq}{qpush}がオ +フセットかfuzzファクターを表示している合，変更されたファイルが正常である +か確認する必要がある． -パッチを二度適用したり，ファイルの間違った場所に適用してしまうのが一番よ -くある間違いだ． - - - +%It's often a good idea to refresh a patch that has applied with an +%offset or fuzz factor; refreshing the patch generates new context +%information that will make it apply cleanly. I say ``often,'' not +%``always,'' because sometimes refreshing a patch will make it fail to +%apply against a different revision of the underlying files. In some +%cases, such as when you're maintaining a patch that must sit on top of +%multiple versions of a source tree, it's acceptable to have a patch +%apply with some fuzz, provided you've verified the results of the +%patching process in such cases. -It's often a good idea to refresh a patch that has applied with an -offset or fuzz factor; refreshing the patch generates new context -information that will make it apply cleanly. I say ``often,'' not -``always,'' because sometimes refreshing a patch will make it fail to -apply against a different revision of the underlying files. In some -cases, such as when you're maintaining a patch that must sit on top of -multiple versions of a source tree, it's acceptable to have a patch -apply with some fuzz, provided you've verified the results of the -patching process in such cases. +オフセットやfuzz factorの出たパッチをリフレッシュするのは多くの場合良い考 +えである．パッチをリフレッシュすると，新しいコンテキスト情報が生成され， +パッチがクリーンに適用できるようになる．「常に」ではななく「多くの場合」 +と断ったのは，パッチをリフレッシュすることで，元のファイルの異なったリビ +ジョンでパッチが適用できなくなることがあるからだ．複数のバージョンのソー +スツリーの上で適用可能なパッチを管理しなければならないような場合などは， +パッチの結果を検証してあるのであればfuzzの出るパッチも許容され得る． %\subsection{Handling rejection} \subsection{リジェクトの取り扱い} -If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error -message and exit. If it has left \sfilename{.rej} files behind, it is -usually best to fix up the rejected hunks before you push more patches -or do any further work. +%If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error +%message and exit. If it has left \sfilename{.rej} files behind, it is +%usually best to fix up the rejected hunks before you push more patches +%or do any further work. + +\hgxcmd{mq}{qpush}はパッチの適用に失敗した場合，エラーメッセージを表示し +て終了する．\sfilename{.rej}ファイルが作られている場合は，通常，さらなる +パッチの追加や新しい作業の前にリジェクトされたhunkについて修正を行うべき +である． -If your patch \emph{used to} apply cleanly, and no longer does because -you've changed the underlying code that your patches are based on, -Mercurial Queues can help; see section~\ref{sec:mq:merge} for details. +%If your patch \emph{used to} apply cleanly, and no longer does because +%you've changed the underlying code that your patches are based on, +%Mercurial Queues can help; see section~\ref{sec:mq:merge} for details. + +それまでパッチがクリーンに適用されており，パッチの対象になっているコード +に変更を加えたために適用できなくなったのなら，Mercurial Queuesの支援を受 +けることができる．詳しい情報はセクション~\ref{sec:mq:merge}を見て欲しい． + +%Unfortunately, there aren't any great techniques for dealing with +%rejected hunks. Most often, you'll need to view the \sfilename{.rej} +%file and edit the target file, applying the rejected hunks by hand. -Unfortunately, there aren't any great techniques for dealing with -rejected hunks. Most often, you'll need to view the \sfilename{.rej} -file and edit the target file, applying the rejected hunks by hand. +残念なことに，リジェクトされたhunkを取り扱う決まった良い方法は存在しな +い．大抵の場合，\sfilename{.rej}ファイルを見てターゲットファイルを編集 +し，リジェクトされたhunkを手で適用することになる． + +%If you're feeling adventurous, Neil Brown, a Linux kernel hacker, +%wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more +%vigorous than \command{patch} in its attempts to make a patch apply. + +冒険が好きなら，Linux kernerハッカーのNeil Brownが書いた +\command{wiggle}~\cite{web:wiggle}を試してみると良い．このコマンドは +\command{patch}よりも精力的にパッチの適用を試みる． -If you're feeling adventurous, Neil Brown, a Linux kernel hacker, -wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more -vigorous than \command{patch} in its attempts to make a patch apply. +%Another Linux kernel hacker, Chris Mason (the author of Mercurial +%Queues), wrote a similar tool called +%\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to +%automating the application of hunks rejected by \command{patch}. The +%\command{mpatch} command can help with four common reasons that a hunk +%may be rejected: -Another Linux kernel hacker, Chris Mason (the author of Mercurial -Queues), wrote a similar tool called -\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to -automating the application of hunks rejected by \command{patch}. The -\command{mpatch} command can help with four common reasons that a hunk -may be rejected: +別のLinux kernerハッカー Chris Mason（Mercurial Queuesの作者でもある．） +は\command{mpatch}~\cite{web:mpatch}というツールを書いた．このコマンドは +\command{patch}コマンドでリジェクトされたhunkの適用を自動化す +る．\command{mpatch}コマンドは，hunkがリジェクトされる主な原因4つに対応 +する: \begin{itemize} -\item The context in the middle of a hunk has changed. -\item A hunk is missing some context at the beginning or end. -\item A large hunk might apply better---either entirely or in - part---if it was broken up into smaller hunks. -\item A hunk removes lines with slightly different content than those - currently present in the file. +%\item The context in the middle of a hunk has changed. +\item hunkの中のコンテキストが変更された +%\item A hunk is missing some context at the beginning or end. +\item hunkの開始部・終端部でコンテキストが見つけられない +%\item A large hunk might apply better---either entirely or in +% part---if it was broken up into smaller hunks. +\item 大きなhunkはもっと上手に適用できる筈だ---hunkを小さなhunkに分割し + て適用する +%\item A hunk removes lines with slightly different content than those +% currently present in the file. +\item hunk内の行が現在ファイルにある行と若干違っている場合，その行を削除 + する \end{itemize} -If you use \command{wiggle} or \command{mpatch}, you should be doubly -careful to check your results when you're done. In fact, -\command{mpatch} enforces this method of double-checking the tool's -output, by automatically dropping you into a merge program when it has -done its job, so that you can verify its work and finish off any -remaining merges. +%If you use \command{wiggle} or \command{mpatch}, you should be doubly +%careful to check your results when you're done. In fact, +%\command{mpatch} enforces this method of double-checking the tool's +%output, by automatically dropping you into a merge program when it has +%done its job, so that you can verify its work and finish off any +%remaining merges. + +\command{wiggle}または\command{mpatch}を使用した場合は，結果に細心の注意 +が必要である．実際には\command{mpatch}はツールの出力で二重チェックを強制 +し，動作が終ると自動的にマージプログラムを起動する．これによって作業を確 +認し，マージを完了することができる． %\section{Getting the best performance out of MQ} \section{MQを最大限に活用する} \label{sec:mq:perf} -MQ is very efficient at handling a large number of patches. I ran -some performance experiments in mid-2006 for a talk that I gave at the -2006 EuroPython conference~\cite{web:europython}. I used as my data -set the Linux 2.6.17-mm1 patch series, which consists of 1,738 -patches. I applied these on top of a Linux kernel repository -containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux -2.6.17. +%MQ is very efficient at handling a large number of patches. I ran +%some performance experiments in mid-2006 for a talk that I gave at the +%2006 EuroPython conference~\cite{web:europython}. I used as my data +%set the Linux 2.6.17-mm1 patch series, which consists of 1,738 +%patches. I applied these on top of a Linux kernel repository +%containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux +%2.6.17. + +MQはとても効率的に大量のパッチを処理することができる．筆者は2006年の中頃， +2006 EuroPython conference~\cite{web:europython}での講演のために性能測定 +を行った．測定に用いたデータはLinux 2.6.17-mm1のパッチシリーズで，1,738 +のパッチを含む．このパッチをLinux kernelリポジトリに適用した．リポジトリ +はLinux 2.6.12-rc2からLinux 2.6.17までの27,472のリビジョンを含んでいる． -On my old, slow laptop, I was able to -\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} all 1,738 patches in 3.5 minutes, -and \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} them all in 30 seconds. (On a -newer laptop, the time to push all patches dropped to two minutes.) I -could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779 -lines of changes to 287 files) in 6.6 seconds. +%On my old, slow laptop, I was able to +%\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} all 1,738 patches in 3.5 minutes, +%and \hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} them all in 30 seconds. (On a +%newer laptop, the time to push all patches dropped to two minutes.) I +%could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779 +%lines of changes to 287 files) in 6.6 seconds. -Clearly, MQ is well suited to working in large trees, but there are a -few tricks you can use to get the best performance of it. +筆者の古く遅いラップトップで，\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}}で +1738のパッチすべてを処理するのに +3.5分，\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}}を行うのに30秒を要した．(新 +しいラップトップではプッシュの所要時間は2分であった．)最大のパッチ +(22.778行で，287のファイルを変更する)に\hgxcmd{mq}{qrefresh}を行ったとこ +ろ，6.6秒を要した． + +%Clearly, MQ is well suited to working in large trees, but there are a +%few tricks you can use to get the best performance of it. + +MQが巨大なツリーでの作業に適しているのは明らかだが，さらに最高の性能を引 +き出すためにいくつかのトリックが使える． -First of all, try to ``batch'' operations together. Every time you -run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working -directory once to make sure you haven't made some changes and then -forgotten to run \hgxcmd{mq}{qrefresh}. On a small tree, the time that -this scan takes is unnoticeable. However, on a medium-sized tree -(containing tens of thousands of files), it can take a second or more. +%First of all, try to ``batch'' operations together. Every time you +%run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working +%directory once to make sure you haven't made some changes and then +%forgotten to run \hgxcmd{mq}{qrefresh}. On a small tree, the time that +%this scan takes is unnoticeable. However, on a medium-sized tree +%(containing tens of thousands of files), it can take a second or more. + +まず第一に，``batch''オペレーションを併用することができ +る．\hgxcmd{mq}{qpush}または\hgxcmd{mq}{qpop}は，ワーキングディレクトリに +変更を加えたのに\hgxcmd{mq}{qrefresh}の実行を忘れていないかどうか調べるた +め，実行時に常にワーキングディレクトリをスキャンする．小規模なツリーでは +気づかない程度の時間しかかからないが，(数万のファイルを持つような)中規模 +のでは数秒の時間を要する． -The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop -multiple patches at a time. You can identify the ``destination -patch'' that you want to end up at. When you \hgxcmd{mq}{qpush} with a -destination specified, it will push patches until that patch is at the -top of the applied stack. When you \hgxcmd{mq}{qpop} to a destination, MQ -will pop patches until the destination patch is at the top. +%The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop +%multiple patches at a time. You can identify the ``destination +%patch'' that you want to end up at. When you \hgxcmd{mq}{qpush} with a +%destination specified, it will push patches until that patch is at the +%top of the applied stack. When you \hgxcmd{mq}{qpop} to a destination, MQ +%will pop patches until the destination patch is at the top. -You can identify a destination patch using either the name of the -patch, or by number. If you use numeric addressing, patches are -counted from zero; this means that the first patch is zero, the second -is one, and so on. +\hgxcmd{mq}{qpush}コマンドと\hgxcmd{mq}{qpop}コマンドは複数のファイルを同 +時にpushまたはpopすることができる．最終目的のパッチがあるなら +ば，\hgxcmd{mq}{qpush}に目的のパッチを指定して実行することで，指定したパッ +チが再上位になるまでパッチをpushする．同様に\hgxcmd{mq}{qpop}に目的のパッ +チを指定すれば，指定したパッチが再上位になるまでパッチをpopする． + +%You can identify a destination patch using either the name of the +%patch, or by number. If you use numeric addressing, patches are +%counted from zero; this means that the first patch is zero, the second +%is one, and so on. + +目的のパッチは名前でも番号でも指定可能である．番号が用いられる場合は，パッ +チは0からカウントされる．つまり最初のパッチは0となり，2番目は1，という風 +になる． %\section{Updating your patches when the underlying code changes} -\section{下位コードの変化に合わせてパッチを更新する} +\section{対象コードの変化に合わせてパッチを更新する} \label{sec:mq:merge} It's common to have a stack of patches on top of an underlying @@ -1303,7 +1373,7 @@ the main repository. %\subsection{A few things to watch out for} -\subsection{監視しておくべきいくつかの点} +\subsection{注意しておくべきいくつかの点} MQ's support for working with a repository full of patches is limited in a few small respects.