# HG changeset patch # User Yoshiki Yazawa # Date 1207838517 -32400 # Node ID cb130184dd23e492cadb7ca6ce554600a49887ee # Parent b8791971ba654a7b1a18aae7b5401b454626975d more mq.tex diff -r b8791971ba65 -r cb130184dd23 ja/mq.tex --- a/ja/mq.tex Mon Mar 31 17:28:24 2008 +0900 +++ b/ja/mq.tex Thu Apr 10 23:41:57 2008 +0900 @@ -835,90 +835,134 @@ はパス名をこの形式で生成し，\hgcmd{import}コマンドとMQはストリップカウン ト1を前提としている． -If you receive a patch from someone that you want to add to your patch -queue, and the patch needs a strip count other than one, you cannot -just \hgxcmd{mq}{qimport} the patch, because \hgxcmd{mq}{qimport} does not yet -have a \texttt{-p} option (see~\bug{311}). - -Your best bet is to -\hgxcmd{mq}{qnew} a patch of your own, then use \cmdargs{patch}{-p\emph{N}} -to apply their patch, followed by \hgcmd{addremove} to pick up any -files added or removed by the patch, followed by \hgxcmd{mq}{qrefresh}. -This complexity may become unnecessary; see~\bug{311} for details. +%If you receive a patch from someone that you want to add to your patch +%queue, and the patch needs a strip count other than one, you cannot +%just \hgxcmd{mq}{qimport} the patch, because \hgxcmd{mq}{qimport} does not yet +%have a \texttt{-p} option (see~\bug{311}). Your best bet is to +%\hgxcmd{mq}{qnew} a patch of your own, then use \cmdargs{patch}{-p\emph{N}} +%to apply their patch, followed by \hgcmd{addremove} to pick up any +%files added or removed by the patch, followed by \hgxcmd{mq}{qrefresh}. +%This complexity may become unnecessary; see~\bug{311} for details. -誰かからパッチを受け取り，パッチキューに追加しようとする時，パッチカウン -トが1以外であれば単に\hgxcmd{mq}{qimport}することはできない．これは -\hgxcmd{mq}{qimport}コマンドがまだ\texttt{-p}オプションを持っていないた -めだ（\bug{311}を参照）． - -一番良さそうなのは，\hgxcmd{mq}{qnew}で新たにパッチを作り， -\cmdargs{patch}{-p\emph{N}}を実行して受け取ったパッチを適用した後， -パッチによって追加されたり削除されたファイルを\hgcmd{addremove}によって -ピックアップし，\hgxcmd{mq}{qrefresh}を実行することである．この複雑な手 -順は将来的には必要なくなるはずだ（\bug{311}を参照）． +誰かからパッチを受け取り，パッチキューに追加するとき，ストリップカウント +が1以外であれば単に\hgxcmd{mq}{qimport}することはできない．これは +\hgxcmd{mq}{qimport}コマンドがまだ\texttt{-p}オプションを持っていないため +だ（\bug{311}を参照）．最も上手くいきそうな方法は，\hgxcmd{mq}{qnew}で新 +たにパッチを作り，\cmdargs{patch}{-p\emph{N}}を実行して受け取ったパッチを +適用した後，パッチによって追加されたり削除されたファイルを +\hgcmd{addremove}によってピックアップし，\hgxcmd{mq}{qrefresh}を実行する +ことである．この複雑な手順は将来的には必要なくなるはずだ（\bug{311}を参 +照）． %\subsection{Strategies for applying a patch} \subsection{パッチ適用のための戦略} -When \command{patch} applies a hunk, it tries a handful of -successively less accurate strategies to try to make the hunk apply. -This falling-back technique often makes it possible to take a patch -that was generated against an old version of a file, and apply it -against a newer version of that file. +%When \command{patch} applies a hunk, it tries a handful of +%successively less accurate strategies to try to make the hunk apply. +%This falling-back technique often makes it possible to take a patch +%that was generated against an old version of a file, and apply it +%against a newer version of that file. -\command{patch}がhunkを適用するとき， +\command{patch}がhunkを適用するとき，いくつかのあまり正確でない戦略を続け +て用いる．このフォールバック手法によって，古いバージョンのファイルに対し +て作成したパッチを新しいファイルに適用することさえしばしば可能となる． +%First, \command{patch} tries an exact match, where the line numbers, +%the context, and the text to be modified must apply exactly. If it +%cannot make an exact match, it tries to find an exact match for the +%context, without honouring the line numbering information. If this +%succeeds, it prints a line of output saying that the hunk was applied, +%but at some \emph{offset} from the original line number. -First, \command{patch} tries an exact match, where the line numbers, -the context, and the text to be modified must apply exactly. If it -cannot make an exact match, it tries to find an exact match for the -context, without honouring the line numbering information. If this -succeeds, it prints a line of output saying that the hunk was applied, -but at some \emph{offset} from the original line number. +最初に，\command{patch}は行番号，コンテキスト，変更されるテキストの正確な +マッチを試みる．正確なマッチができない場合，行番号を無視してコンテキスト +の正確なマッチを試みる．これが成功すれば，hunkが適用されたが，\emph{オフ +セット}が生じたというメッセージを表示する． + +%If a context-only match fails, \command{patch} removes the first and +%last lines of the context, and tries a \emph{reduced} context-only +%match. If the hunk with reduced context succeeds, it prints a message +%saying that it applied the hunk with a \emph{fuzz factor} (the number +%after the fuzz factor indicates how many lines of context +%\command{patch} had to trim before the patch applied). -If a context-only match fails, \command{patch} removes the first and -last lines of the context, and tries a \emph{reduced} context-only -match. If the hunk with reduced context succeeds, it prints a message -saying that it applied the hunk with a \emph{fuzz factor} (the number -after the fuzz factor indicates how many lines of context -\command{patch} had to trim before the patch applied). +コンテキストのみのマッチが失敗すると，\command{patch}はコンテキストの最初 +と最後の行を削り，コンテキストの\emph{縮小}マッチを試みる．縮小コンテキス +トによるhunkが成功すると，hunkが適用されたことと\emph{fuzz ファクター}を +含むメッセージを表示する．（fuzzファクターの後ろの数字は， +\command{patch}コマンドが，パッチを適用する前にコンテキストの何行を削除す +る必要があったのかを示す．） -When neither of these techniques works, \command{patch} prints a -message saying that the hunk in question was rejected. It saves -rejected hunks (also simply called ``rejects'') to a file with the -same name, and an added \sfilename{.rej} extension. It also saves an -unmodified copy of the file with a \sfilename{.orig} extension; the -copy of the file without any extensions will contain any changes made -by hunks that \emph{did} apply cleanly. If you have a patch that -modifies \filename{foo} with six hunks, and one of them fails to -apply, you will have: an unmodified \filename{foo.orig}, a -\filename{foo.rej} containing one hunk, and \filename{foo}, containing -the changes made by the five successful five hunks. +%When neither of these techniques works, \command{patch} prints a message +%saying that the hunk in question was rejected. It saves rejected hunks +%(also simply called ``rejects'') to a file with the same name, and an +%added \sfilename{.rej} extension. It also saves an unmodified copy of +%the file with a \sfilename{.orig} extension; the copy of the file +%without any extensions will contain any changes made by hunks that +%\emph{did} apply cleanly. If you have a patch that modifies +%\filename{foo} with six hunks, and one of them fails to apply, you will +%have: an unmodified \filename{foo.orig}, a \filename{foo.rej} containing +%one hunk, and \filename{foo}, containing the changes made by the five +%successful five hunks. + +どちらも上手くいかなかった場合，\command{patch}はhunkがリジェクトされたと +いうメッセージを表示する．コマンドはリジェクトされたhunk（あるいは単に +``rejects''）を同名で拡張子\sfilename{.rej}のファイルにセーブする．コマン +ドは同時に無変更のファイルを\sfilename{.orig}という拡張子でセーブする。拡 +張子のないファイルのコピーは，hunkからクリーンに適用された変更を全て含む． +\filename{foo}というファイルを変更する6つのhunkを含むパッチファイルがあり， +その内の1つが適用できなかったとすると，無変更のファイル +\filename{foo.orig}，hunk1つを含むファイル\filename{foo.rej}，正しく適用 +された5つのhunkを含むファイル\filename{foo}が生成される． %\subsection{Some quirks of patch representation} \subsection{パッチ表現の奇妙な点} -There are a few useful things to know about how \command{patch} works -with files. +%There are a few useful things to know about how \command{patch} works +%with files. +%\begin{itemize} +%\item This should already be obvious, but \command{patch} cannot +% handle binary files. +%\item Neither does it care about the executable bit; it creates new +% files as readable, but not executable. +%\item \command{patch} treats the removal of a file as a diff between +% the file to be removed and the empty file. So your idea of ``I +% deleted this file'' looks like ``every line of this file was +% deleted'' in a patch. +%\item It treats the addition of a file as a diff between the empty +% file and the file to be added. So in a patch, your idea of ``I +% added this file'' looks like ``every line of this file was added''. +%\item It treats a renamed file as the removal of the old name, and the +% addition of the new name. This means that renamed files have a big +% footprint in patches. (Note also that Mercurial does not currently +% try to infer when files have been renamed or copied in a patch.) +%\item \command{patch} cannot represent empty files, so you cannot use +% a patch to represent the notion ``I added this empty file to the +% tree''. +%\end{itemize} + +\command{patch}がファイルにどのように作用するか，有用な点をいくつか述べ +る． \begin{itemize} -\item This should already be obvious, but \command{patch} cannot - handle binary files. -\item Neither does it care about the executable bit; it creates new - files as readable, but not executable. -\item \command{patch} treats the removal of a file as a diff between - the file to be removed and the empty file. So your idea of ``I - deleted this file'' looks like ``every line of this file was - deleted'' in a patch. -\item It treats the addition of a file as a diff between the empty - file and the file to be added. So in a patch, your idea of ``I - added this file'' looks like ``every line of this file was added''. -\item It treats a renamed file as the removal of the old name, and the - addition of the new name. This means that renamed files have a big - footprint in patches. (Note also that Mercurial does not currently - try to infer when files have been renamed or copied in a patch.) -\item \command{patch} cannot represent empty files, so you cannot use - a patch to represent the notion ``I added this empty file to the - tree''. + \item すでに明白だが，\command{patch}はバイナリファイルを扱うことはでき + ない． + \item 実行ビットを考慮しないだけでなく，新しいファイルを読み取り可能属 + 性で作成し，実行可能属性は付けない． + \item \command{patch}コマンドはファイルの削除を削除されるファイルと中身 + がからのファイルとの差分として扱う．従って，ファイルを削除するとい + うことは，パッチファイルの中ではファイルの中の全ての行を削除するこ + とと等価である． + \item \command{patch}コマンドはファイルの追加を空のファイルと追加される + ファイルの差分として扱う．従ってファイルの追加はパッチファイルの中 + ではファイルに全ての行を追加することと等価である． + \item \command{patch}コマンドは名前の変更されたファイルを旧名のファイル + の削除と新しいファイルの追加として扱う．従って名前の変更されたファ + イルはパッチ内で大きなフットプリントを占める．（Mercurialは現在の + ところ，パッチ内でファイルがリネームされたのか，コピーされたのか + を関知しない） + \item \command{patch}コマンドは中身の空のファイルを表現できない．従って + パッチファイルを「空のファイルをツリーに追加する」という用途に使 + うことはできない． \end{itemize} %\subsection{Beware the fuzz} @@ -928,10 +972,22 @@ 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 +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. +あるオフセットやfuzz factorの位置へのhunkの適用は多くの場合全く問題なく成 +功するが，不正確なマッチを用いた場合，パッチを適用したファイルを壊してい +る可能性が残る． + +パッチを二度適用したり，ファイルの間違った場所に適用してしまうのが一番よ +くある間違いだ． + + + + 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