# HG changeset patch # User Yoshiki Yazawa # Date 1217561905 -32400 # Node ID 0b99bf82b573f833f9250f7c04b39ea14b0548a7 # Parent 6da6c5741e90ef1e7dcf2db1f025398d03520d98 more mq.tex diff -r 6da6c5741e90 -r 0b99bf82b573 ja/mq.tex --- a/ja/mq.tex Sun Jul 13 04:11:36 2008 +0900 +++ b/ja/mq.tex Fri Aug 01 12:38:25 2008 +0900 @@ -1322,21 +1322,32 @@ %of those start-at-zero counting systems); the second is patch one; and %so on -インデックスがそれほど違わないパッチへの参照は +インデックスがあまり違わないパッチの参照．\hgxcmd{mq}{qseries}で最初に表 +示されるパッチはパッチ0(これも0から数え始める)で，2番目はパッチ1のように +続く． -MQ also makes it easy to work with patches when you are using normal -Mercurial commands. Every command that accepts a changeset ID will -also accept the name of an applied patch. MQ augments the tags -normally in the repository with an eponymous one for each applied -patch. In addition, the special tags \index{tags!special tag - names!\texttt{qbase}}\texttt{qbase} and \index{tags!special tag - names!\texttt{qtip}}\texttt{qtip} identify the ``bottom-most'' and -topmost applied patches, respectively. +%MQ also makes it easy to work with patches when you are using normal +%Mercurial commands. Every command that accepts a changeset ID will +%also accept the name of an applied patch. MQ augments the tags +%normally in the repository with an eponymous one for each applied +%patch. In addition, the special tags \index{tags!special tag +% names!\texttt{qbase}}\texttt{qbase} and \index{tags!special tag +% names!\texttt{qtip}}\texttt{qtip} identify the ``bottom-most'' and +%topmost applied patches, respectively. + +MQは，通常のMercurialコマンドを使う時のも簡単にしている．全てのコマンドは +チェンジセットIDと適用されたパッチの番号を受け付ける．MQは，リポジトリに +適用されたパッチの名前のついたタグを受け付ける．さらに，最下位の適用され +たパッチを表す特別なタグ\index{tags!special tag +names!\texttt{qbase}}\texttt{qbase}と，最上位を表す特別なタグ +\index{tags!special tag names!\texttt{qtip}}\texttt{qtip}も受け付ける． %These additions to Mercurial's normal tagging capabilities make %dealing with patches even more of a breeze. + Mercurialの通常のタグ機能へのこれらの追加は，パッチの取り扱いにおいて大き な意味を持つ． + \begin{itemize} %\item Want to patchbomb a mailing list with your latest series of % changes? @@ -1351,151 +1362,243 @@ 参照のこと．) %\item Need to see all of the patches since \texttt{foo.patch} that % have touched files in a subdirectory of your tree? - \item \texttt{foo.patch}以降のすべてのパッチを見たいか？ - -ツリーの中のサブツリー - + \item ツリー中のサブディレクトリに含まれるファイルに触れた + \texttt{foo.patch}以降のパッチを全て見たいか？ \begin{codesample4} hg log -r foo.patch:qtip \emph{subdir} \end{codesample4} \end{itemize} -Because MQ makes the names of patches available to the rest of -Mercurial through its normal internal tag machinery, you don't need to -type in the entire name of a patch when you want to identify it by -name. +%Because MQ makes the names of patches available to the rest of +%Mercurial through its normal internal tag machinery, you don't need to +%type in the entire name of a patch when you want to identify it by +%name. + +MQでのパッチの名称は，内部のタグ機構を用いているため，Mercurialの他の部分 +でも利用可能である．名称を指定する時，名称全てを入力する必要はない． \begin{figure}[ht] \interaction{mq.id.output} - \caption{Using MQ's tag features to work with patches} +% \caption{Using MQ's tag features to work with patches} + \caption{パッチを扱うためMQのタグ機能を利用する} \label{ex:mq:id} \end{figure} -Another nice consequence of representing patch names as tags is that -when you run the \hgcmd{log} command, it will display a patch's name -as a tag, simply as part of its normal output. This makes it easy to -visually distinguish applied patches from underlying ``normal'' -revisions. Figure~\ref{ex:mq:id} shows a few normal Mercurial -commands in use with applied patches. +%Another nice consequence of representing patch names as tags is that +%when you run the \hgcmd{log} command, it will display a patch's name +%as a tag, simply as part of its normal output. This makes it easy to +%visually distinguish applied patches from underlying ``normal'' +%revisions. Figure~\ref{ex:mq:id} shows a few normal Mercurial +%commands in use with applied patches. + +パッチ名をタグとして取り扱うことのもう一つの利点は，\hgcmd{log}コマンド +を実行した時，通常出力の一部にパッチ名をタグとして表示する点である．この +ため，適用したパッチは下位の``通常の''リビジョンと視覚的に区別し易くなる． +図~\ref{ex:mq:id}にいくつかの通常のMercurialコマンドを適用済みパッチと共 +に使用した場合を示す． %\section{Useful things to know about} \section{知っておくべきいくつかの点} -There are a number of aspects of MQ usage that don't fit tidily into -sections of their own, but that are good to know. Here they are, in -one place. +%There are a number of aspects of MQ usage that don't fit tidily into +%sections of their own, but that are good to know. Here they are, in +%one place. + +MQの使用法には個別に取り上げるほどではないが，知っておくと良いいくつかの +点がある．ここではそれらをまとめて取り上げる． \begin{itemize} -\item Normally, when you \hgxcmd{mq}{qpop} a patch and \hgxcmd{mq}{qpush} it - again, the changeset that represents the patch after the pop/push - will have a \emph{different identity} than the changeset that - represented the hash beforehand. See - section~\ref{sec:mqref:cmd:qpush} for information as to why this is. -\item It's not a good idea to \hgcmd{merge} changes from another - branch with a patch changeset, at least if you want to maintain the - ``patchiness'' of that changeset and changesets below it on the - patch stack. If you try to do this, it will appear to succeed, but - MQ will become confused. +%\item Normally, when you \hgxcmd{mq}{qpop} a patch and \hgxcmd{mq}{qpush} it +% again, the changeset that represents the patch after the pop/push +% will have a \emph{different identity} than the changeset that +% represented the hash beforehand. See +% section~\ref{sec:mqref:cmd:qpush} for information as to why this is. +\item パッチを\hgxcmd{mq}{qpop}した後で再び\hgxcmd{mq}{qpush}する + と，pop/pushした後のチェンジセットは，以前のチェンジセットと異なる + アイデンティティを持ち，ハッシュ値が異なる．この理由についてはセク + ション~\ref{sec:mqref:cmd:qpush}を参照されたい． +%\item It's not a good idea to \hgcmd{merge} changes from another +% branch with a patch changeset, at least if you want to maintain the +% ``patchiness'' of that changeset and changesets below it on the +% patch stack. If you try to do this, it will appear to succeed, but +% MQ will become confused. +\item \hgcmd{merge}が他のブランチのパッチチェンジセットをマージすること + は，そのチェンジセットとパッチスタックに積み込まれた他のチェンジセッ + トとの間で一貫性を維持しようとするのであれば避けるべきである．これ + を試みた場合，一見成功したように見えてもMQは混乱状態に陥ってしま + う． \end{itemize} %\section{Managing patches in a repository} \section{リポジトリ内でのパッチの管理} \label{sec:mq:repo} -Because MQ's \sdirname{.hg/patches} directory resides outside a -Mercurial repository's working directory, the ``underlying'' Mercurial -repository knows nothing about the management or presence of patches. +%Because MQ's \sdirname{.hg/patches} directory resides outside a +%Mercurial repository's working directory, the ``underlying'' Mercurial +%repository knows nothing about the management or presence of patches. + +MQの\sdirname{.hg/patches}ディレクトリはMercurialリポジトリのワーキング +ディレクトリの外にあるので，``下位の''Mercurialリポジトリはパッチの管理 +や，その損愛児対について何も知らない． -This presents the interesting possibility of managing the contents of -the patch directory as a Mercurial repository in its own right. This -can be a useful way to work. For example, you can work on a patch for -a while, \hgxcmd{mq}{qrefresh} it, then \hgcmd{commit} the current state of -the patch. This lets you ``roll back'' to that version of the patch -later on. +%This presents the interesting possibility of managing the contents of +%the patch directory as a Mercurial repository in its own right. This +%can be a useful way to work. For example, you can work on a patch for +%a while, \hgxcmd{mq}{qrefresh} it, then \hgcmd{commit} the current state of +%the patch. This lets you ``roll back'' to that version of the patch +%later on. + +このことから，パッチディレクトリの管理を独立したMercurialリポジトリとして +行うことができるのではないかという興味が生まれる．実際この方法は有効な方 +法となり得る．例えば，しばらくの間1つのパッチについて作業を行った後 +で，\hgxcmd{mq}{qrefresh}を行い，パッチの現在の状態を\hgcmd{commit}する +ことができる．これによって，後でこのパッチを``ロールバック''することが可 +能となる． -You can then share different versions of the same patch stack among -multiple underlying repositories. I use this when I am developing a -Linux kernel feature. I have a pristine copy of my kernel sources for -each of several CPU architectures, and a cloned repository under each -that contains the patches I am working on. When I want to test a -change on a different architecture, I push my current patches to the -patch repository associated with that kernel tree, pop and push all of -my patches, and build and test that kernel. +%You can then share different versions of the same patch stack among +%multiple underlying repositories. I use this when I am developing a +%Linux kernel feature. I have a pristine copy of my kernel sources for +%each of several CPU architectures, and a cloned repository under each +%that contains the patches I am working on. When I want to test a +%change on a different architecture, I push my current patches to the +%patch repository associated with that kernel tree, pop and push all of +%my patches, and build and test that kernel. -Managing patches in a repository makes it possible for multiple -developers to work on the same patch series without colliding with -each other, all on top of an underlying source base that they may or -may not control. +複数の下位リポジトリの間で，同じパッチスタックの異なるバージョンを共有す +ることができる．筆者はこれをLinuxカーネルの機能を開発する時に利用してい +る．いくつかのCPUアーキテクチャの各々に対してまっさらなカーネルソースのリ +ポジトリを用意し，作業中のパッチを含むリポジトリをそれらの間でクローンし +ている．変更を異なるアーキテクチャでテストしたい時は，現在のパッチをその +アーキテクチャ用のカーネルツリーと結び付いたパッチのリポジトリへプッシュ +し，すべてのパッチをpop，pushしてカーネルのビルドとテストを行っている． + +%Managing patches in a repository makes it possible for multiple +%developers to work on the same patch series without colliding with +%each other, all on top of an underlying source base that they may or +%may not control. + +リポジトリ内でパッチを管理すると，複数の開発者が同じパッチシリーズの上で +衝突することなく作業できるようになる．これは彼らが下位のソースベースをコ +ントロールできるか否かに関わりがない． %\subsection{MQ support for patch repositories} \subsection{MQによるパッチリポジトリサポート} -MQ helps you to work with the \sdirname{.hg/patches} directory as a -repository; when you prepare a repository for working with patches -using \hgxcmd{mq}{qinit}, you can pass the \hgxopt{mq}{qinit}{-c} option to -create the \sdirname{.hg/patches} directory as a Mercurial repository. +%MQ helps you to work with the \sdirname{.hg/patches} directory as a +%repository; when you prepare a repository for working with patches +%using \hgxcmd{mq}{qinit}, you can pass the \hgxopt{mq}{qinit}{-c} option to +%create the \sdirname{.hg/patches} directory as a Mercurial repository. + +MQは\sdirname{.hg/patches}ディレクトリをリポジトリとして使いながら作業す +ることをサポートしている．パッチを扱う作業用のリポジトリを +\hgxcmd{mq}{qinit}で作成する時，\hgxopt{mq}{qinit}{-c}を渡して +\sdirname{.hg/patches}ディレクトリをMercurialリポジトリにすることができる． \begin{note} - If you forget to use the \hgxopt{mq}{qinit}{-c} option, you can simply go - into the \sdirname{.hg/patches} directory at any time and run - \hgcmd{init}. Don't forget to add an entry for the - \sfilename{status} file to the \sfilename{.hgignore} file, though +% If you forget to use the \hgxopt{mq}{qinit}{-c} option, you can simply go +% into the \sdirname{.hg/patches} directory at any time and run +% \hgcmd{init}. Don't forget to add an entry for the +% \sfilename{status} file to the \sfilename{.hgignore} file, though +% (\hgcmdargs{qinit}{\hgxopt{mq}{qinit}{-c}} does this for you +% automatically); you \emph{really} don't want to manage the +% \sfilename{status} file. - (\hgcmdargs{qinit}{\hgxopt{mq}{qinit}{-c}} does this for you - automatically); you \emph{really} don't want to manage the - \sfilename{status} file. + \hgxopt{mq}{qinit}{-c}オプションを忘れた場合はいつでも + \sdirname{.hg/patches}に入って\hgcmd{init}を実行すればよ + い．\sfilename{status}ファイルを\sfilename{.hgignore}ファイルに追加する + のを忘れないこと．(\hgcmdargs{qinit}{\hgxopt{mq}{qinit}{-c}}はこれを自動 + 的に行う．）\sfilename{status}をバージョン管理する必要は\emph{全くない}． \end{note} -As a convenience, if MQ notices that the \dirname{.hg/patches} -directory is a repository, it will automatically \hgcmd{add} every -patch that you create and import. +%As a convenience, if MQ notices that the \dirname{.hg/patches} +%directory is a repository, it will automatically \hgcmd{add} every +%patch that you create and import. + +\dirname{.hg/patches}がリポジトリの時は，MQは便利のためにこれまで作成し， +インポートしたすべてのパッチを自動的に\hgcmd{add}する． + +%MQ provides a shortcut command, \hgxcmd{mq}{qcommit}, that runs +%\hgcmd{commit} in the \sdirname{.hg/patches} directory. This saves +%some bothersome typing. -MQ provides a shortcut command, \hgxcmd{mq}{qcommit}, that runs -\hgcmd{commit} in the \sdirname{.hg/patches} directory. This saves -some bothersome typing. +MQはショートカットコマンド\hgxcmd{mq}{qcommit}を持つ．このコマンドは +\hgcmd{commit}コマンドを\sdirname{.hg/patches}ディレクトリの中で実行す +る．これによって繁雑な入力を省くことができる． -Finally, as a convenience to manage the patch directory, you can -define the alias \command{mq} on Unix systems. For example, on Linux -systems using the \command{bash} shell, you can include the following -snippet in your \tildefile{.bashrc}. +%Finally, as a convenience to manage the patch directory, you can +%define the alias \command{mq} on Unix systems. For example, on Linux +%systems using the \command{bash} shell, you can include the following +%snippet in your \tildefile{.bashrc}. + +パッチディレクトリの管理のためにUNIX環境なら\command{mq}というエイリアス +を作っておくと便利だ．Linuxでは\command{bash}シェルの設定ファイル +\tildefile{.bashrc}にこれを定義しておく． \begin{codesample2} alias mq=`hg -R \$(hg root)/.hg/patches' \end{codesample2} -You can then issue commands of the form \cmdargs{mq}{pull} from -the main repository. +%You can then issue commands of the form \cmdargs{mq}{pull} from +%the main repository. + +メインリポジトリから\cmdargs{mq}{pull}を実行することができる %\subsection{A few things to watch out for} \subsection{注意しておくべきいくつかの点} -MQ's support for working with a repository full of patches is limited -in a few small respects. +%MQ's support for working with a repository full of patches is limited +%in a few small respects. + +MQが大量のパッチのあるリポジトリを扱う際に，いくつかの小さな点から制限が +ある． -MQ cannot automatically detect changes that you make to the patch -directory. If you \hgcmd{pull}, manually edit, or \hgcmd{update} -changes to patches or the \sfilename{series} file, you will have to -\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} and then -\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} in the underlying repository to -see those changes show up there. If you forget to do this, you can -confuse MQ's idea of which patches are applied. +%MQ cannot automatically detect changes that you make to the patch +%directory. If you \hgcmd{pull}, manually edit, or \hgcmd{update} +%changes to patches or the \sfilename{series} file, you will have to +%\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}} and then +%\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}} in the underlying repository to +%see those changes show up there. If you forget to do this, you can +%confuse MQ's idea of which patches are applied. + +MQは，パッチディレクトリに対して行われた変更を自動的に検出することはでき +ない．パッチファイルや\sfilename{series}に対して\hgcmd{pull}を行ったり， +手で編集したり，\hgcmd{update}を行った場合 +は，下位のリポジトリに対して\hgcmdargs{qpop}{\hgxopt{mq}{qpop}{-a}}と +\hgcmdargs{qpush}{\hgxopt{mq}{qpush}{-a}}を行い，変更を知らせる必要があ +る．これを忘れるとMQはどのパッチが適用されたのか把握できなくなってしまう． + %\section{Third party tools for working with patches} \section{パッチ向けサードパーティツール} \label{sec:mq:tools} -Once you've been working with patches for a while, you'll find -yourself hungry for tools that will help you to understand and -manipulate the patches you're dealing with. +%Once you've been working with patches for a while, you'll find +%yourself hungry for tools that will help you to understand and +%manipulate the patches you're dealing with. + +しばらくパッチを使った作業をしていると，パッチを取り扱う助けとなるような +ツールが欲しくなるに違いない． + +%The \command{diffstat} command~\cite{web:diffstat} generates a +%histogram of the modifications made to each file in a patch. It +%provides a good way to ``get a sense of'' a patch---which files it +%affects, and how much change it introduces to each file and as a -The \command{diffstat} command~\cite{web:diffstat} generates a -histogram of the modifications made to each file in a patch. It -provides a good way to ``get a sense of'' a patch---which files it -affects, and how much change it introduces to each file and as a -whole. (I find that it's a good idea to use \command{diffstat}'s -\cmdopt{diffstat}{-p} option as a matter of course, as otherwise it -will try to do clever things with prefixes of file names that -inevitably confuse at least me.) +%whole. (I find that it's a good idea to use \command{diffstat}'s +%\cmdopt{diffstat}{-p} option as a matter of course, as otherwise it +%will try to do clever things with prefixes of file names that +%inevitably confuse at least me.) + +\command{diffstat}コマンド~\cite{web:diffstat}はパッチ内のそれぞれのファ +イルへの変更のヒストグラムを生成する． + +これは，パッチが影響を及ぼすファイルを把握したり，全体でそれぞれのファイ +ルへどの程度変更を加えるのか把握するのに役立つ． +(\command{diffstat}コマンドの\cmdopt{diffstat}{-p}オプションが + + +) + \begin{figure}[ht] \interaction{mq.tools.tools} @@ -1550,44 +1653,76 @@ %\subsection{Manage ``trivial'' patches} \subsection{``トリビアル''なパッチの管理} -Because the overhead of dropping files into a new Mercurial repository -is so low, it makes a lot of sense to manage patches this way even if -you simply want to make a few changes to a source tarball that you -downloaded. +%Because the overhead of dropping files into a new Mercurial repository +%is so low, it makes a lot of sense to manage patches this way even if +%you simply want to make a few changes to a source tarball that you +%downloaded. -Begin by downloading and unpacking the source tarball, -and turning it into a Mercurial repository. +ファイルをMercurialリポジトリに追加するオーバヘッドは小さい．このため，た +とえソースのtarアーカイブへ少数の変更を加えるだけだとしても，パッチをリポ +ジトリで管理するのは良い方法である． + +%Begin by downloading and unpacking the source tarball, +%and turning it into a Mercurial repository. +%\interaction{mq.tarball.download} + +ソースtarballをダウンロードして展開し，これをMercurialリポジトリに変換す +る． \interaction{mq.tarball.download} -Continue by creating a patch stack and making your changes. +%Continue by creating a patch stack and making your changes. +%\interaction{mq.tarball.qinit} + +パッチスタックを作り変更を行う． \interaction{mq.tarball.qinit} -Let's say a few weeks or months pass, and your package author releases -a new version. First, bring their changes into the repository. +%Let's say a few weeks or months pass, and your package author releases +%a new version. First, bring their changes into the repository. +%\interaction{mq.tarball.newsource} +%The pipeline starting with \hgcmd{locate} above deletes all files in +%the working directory, so that \hgcmd{commit}'s +%\hgopt{commit}{--addremove} option can actually tell which files have +%really been removed in the newer version of the source. + +数週間から数カ月経った時，パッケージの作者が新しいバージョンをリリースし +たとしよう．その場合，まず新しいバージョンとの差分をリポジトリに取り込む． \interaction{mq.tarball.newsource} -The pipeline starting with \hgcmd{locate} above deletes all files in -the working directory, so that \hgcmd{commit}'s -\hgopt{commit}{--addremove} option can actually tell which files have -really been removed in the newer version of the source. +\hgcmd{locate}の出力をパイプで繋いでワーキングディレクトリのすべてのファ +イルを消去し，\hgcmd{commit}コマンドの\hgopt{commit}{--addremove}オプショ +ンを使って実際にどのファイルが新しいバージョンのソースで削除されたのか指 +定する． -Finally, you can apply your patches on top of the new tree. +%Finally, you can apply your patches on top of the new tree. +%\interaction{mq.tarball.repush} + +最後にパッチを新しいツリーに適用する． \interaction{mq.tarball.repush} %\subsection{Combining entire patches} \subsection{パッチ同士を結合する} \label{sec:mq:combine} -MQ provides a command, \hgxcmd{mq}{qfold} that lets you combine entire -patches. This ``folds'' the patches you name, in the order you name -them, into the topmost applied patch, and concatenates their -descriptions onto the end of its description. The patches that you -fold must be unapplied before you fold them. +%MQ provides a command, \hgxcmd{mq}{qfold} that lets you combine entire +%patches. This ``folds'' the patches you name, in the order you name +%them, into the topmost applied patch, and concatenates their +%descriptions onto the end of its description. The patches that you +%fold must be unapplied before you fold them. + +MQにはパッチ全体を結合する\hgxcmd{mq}{qfold}というコマンドがある．このコ +マンドは名前をつけたパッチを名付けた順番で再上位の適用済みパッチに畳み込 +む．各々のパッチの説明は結合されてパッチの説明の末尾に追加される．畳み込 +むパッチはすでに適用されていてはならない． -The order in which you fold patches matters. If your topmost applied -patch is \texttt{foo}, and you \hgxcmd{mq}{qfold} \texttt{bar} and -\texttt{quux} into it, you will end up with a patch that has the same -effect as if you applied first \texttt{foo}, then \texttt{bar}, -followed by \texttt{quux}. +%The order in which you fold patches matters. If your topmost applied +%patch is \texttt{foo}, and you \hgxcmd{mq}{qfold} \texttt{bar} and +%\texttt{quux} into it, you will end up with a patch that has the same +%effect as if you applied first \texttt{foo}, then \texttt{bar}, +%followed by \texttt{quux}. + +パッチを畳み込む順番は重要である．今，再上位の適用済みパッチが +\texttt{foo}だとして，\hgxcmd{mq}{qfold} \texttt{bar}と\texttt{quux}を行 +うと，パッチは\texttt{foo}, then \texttt{bar}, \texttt{quux}の順番でパッ +チを適用したのと同じ効果を持つことになる． %\subsection{Merging part of one patch into another} \subsection{パッチの一部分を別のパッチへマージする} @@ -1595,46 +1730,69 @@ %Merging \emph{part} of one patch into another is more difficult than %combining entire patches. -パッチの\emph{一部}を別のパッチへマージすることは，パッチを結合するより -は難しい． +パッチの\emph{一部}を別のパッチへマージすることは，パッチを結合するよりは +難しい． -If you want to move changes to entire files, you can use -\command{filterdiff}'s \cmdopt{filterdiff}{-i} and -\cmdopt{filterdiff}{-x} options to choose the modifications to snip -out of one patch, concatenating its output onto the end of the patch -you want to merge into. You usually won't need to modify the patch -you've merged the changes from. Instead, MQ will report some rejected -hunks when you \hgxcmd{mq}{qpush} it (from the hunks you moved into the -other patch), and you can simply \hgxcmd{mq}{qrefresh} the patch to drop -the duplicate hunks. +%If you want to move changes to entire files, you can use +%\command{filterdiff}'s \cmdopt{filterdiff}{-i} and +%\cmdopt{filterdiff}{-x} options to choose the modifications to snip +%out of one patch, concatenating its output onto the end of the patch +%you want to merge into.You usually won't need to modify the patch +%you've merged the changes from. Instead, MQ will report some rejected +%hunks when you \hgxcmd{mq}{qpush} it (from the hunks you moved into the +%other patch), and you can simply \hgxcmd{mq}{qrefresh} the patch to drop +%the duplicate hunks. - +変更をファイルの集合全体に移動する場合，\command{filterdiff}に +\cmdopt{filterdiff}{-i}と\cmdopt{filterdiff}{-x}を付け， +一つのパッチから取る去る変更，パッチの末尾に結合する変更を選ぶ． +通常の場合，変更を取り出したパッチを変更する必要はない．その代わり，MQは +(他のパッチに移動したhunkから)\hgxcmd{mq}{qpush}した時にリジェクトされた +hunkを報告する． +%If you have a patch that has multiple hunks modifying a file, and you +%only want to move a few of those hunks, the job becomes more messy, +%but you can still partly automate it. Use \cmdargs{lsdiff}{-nvv} to +%print some metadata about the patch. +%\interaction{mq.tools.lsdiff} -If you have a patch that has multiple hunks modifying a file, and you -only want to move a few of those hunks, the job becomes more messy, -but you can still partly automate it. Use \cmdargs{lsdiff}{-nvv} to -print some metadata about the patch. -\interaction{mq.tools.lsdiff} +パッチに一つのファイルを変更する複数のhunkがあり，その中の一部を移動した +い場合は，作業はもっとややこしいものになるが，依然として一部は自動化する +ことができる．\cmdargs{lsdiff}{-nvv}コマンドでパッチのメタデータを表示す +る．\interaction{mq.tools.lsdiff} -This command prints three different kinds of number: +%This command prints three different kinds of number: +このコマンドは3つの異なる番号を出力する: \begin{itemize} -\item (in the first column) a \emph{file number} to identify each file - modified in the patch; -\item (on the next line, indented) the line number within a modified - file where a hunk starts; and -\item (on the same line) a \emph{hunk number} to identify that hunk. +%\item (in the first column) a \emph{file number} to identify each file +% modified in the patch; +\item (最初の列) このパッチで変更されるファイルを識別するための\emph{ファ + イル番号} +%\item (on the next line, indented) the line number within a modified +% file where a hunk starts; and +\item (次の行でインデントされている) 変更されたファイルの中でhunが始まる + 行番号 +%\item (on the same line) a \emph{hunk number} to identify that hunk. +\item (それと同じ行) 当該hunkを識別する\emph{hunk番号} \end{itemize} -You'll have to use some visual inspection, and reading of the patch, -to identify the file and hunk numbers you'll want, but you can then -pass them to to \command{filterdiff}'s \cmdopt{filterdiff}{--files} -and \cmdopt{filterdiff}{--hunks} options, to select exactly the file -and hunk you want to extract. +%You'll have to use some visual inspection, and reading of the patch, +%to identify the file and hunk numbers you'll want, but you can then +%pass them to to \command{filterdiff}'s \cmdopt{filterdiff}{--files} +%and \cmdopt{filterdiff}{--hunks} options, to select exactly the file +%and hunk you want to extract. -Once you have this hunk, you can concatenate it onto the end of your -destination patch and continue with the remainder of -section~\ref{sec:mq:combine}. +必要なファイルとhunk番号を見つけるために，パッチを読むなどして目視で確認 +する必要がある．その番号は，extractするファイルとhunkを選ぶために +\command{filterdiff}コマンドの\cmdopt{filterdiff}{--files}と +\cmdopt{filterdiff}{--hunks}オプションで使える． + +%Once you have this hunk, you can concatenate it onto the end of your +%destination patch and continue with the remainder of +%section~\ref{sec:mq:combine}. + +このhunkができたら，目的のパッチの末尾に結合し，セクションの残りの部分を +続けることができる~\ref{sec:mq:combine}． %\section{Differences between quilt and MQ} \section{quiltとMQの違い} @@ -1658,7 +1816,6 @@ \hgcmd{add}と\hgcmd{remove}が対応する．また，quiltの\texttt{edit}コマンド に対応するMQコマンドはない． - %%% Local Variables: %%% mode: yatex %%% TeX-master: "00book"