changeset 354:4991d84ba9d6

finished mq-collab.tex

--- a/ja/mq-collab.tex	Tue Aug 19 19:32:28 2008 +0900
+++ b/ja/mq-collab.tex	Sun Aug 31 04:00:40 2008 +0900
@@ -367,113 +367,202 @@
 %\section{Dividing up the \sfilename{series} file}
 \section{\sfilename{series}$B%U%!%$%k$rJ,3d$9$k(B}
 
-I categorise the patches in the \sfilename{series} file into a number
-of logical groups.  Each section of like patches begins with a block
-of comments that describes the purpose of the patches that follow.
+%I categorise the patches in the \sfilename{series} file into a number
+%of logical groups.  Each section of like patches begins with a block
+%of comments that describes the purpose of the patches that follow.
 
-The sequence of patch groups that I maintain follows.  The ordering of
-these groups is important; I'll describe why after I introduce the
-groups.
+$BI.<T$O(B\sfilename{series}$B%U%!%$%k$N%Q%C%A$r$$$/$D$+$NO@M}E*$J%0%k!<%W$K%+(B
+$B%F%4%i%$%:$7$F$$$k!%%Q%C%A$N$=$l$>$l$N%;%/%7%g%s$O$"$H$KB3$/%Q%C%A$,2?$G(B
+$B$"$k$+@bL@$9$k%3%a%s%H%V%m%C%/$G;O$^$C$F$$$k!%(B
+
+%The sequence of patch groups that I maintain follows.  The ordering of
+%these groups is important; I'll describe why after I introduce the
+%groups.
+$B$=$N8e$K%a%s%F%J%s%9$7$F$$$k%Q%C%A%0%k!<%W$,O"$J$k!%%0%k!<%W$r@0M}$9$k$3(B
+$B$H$O=EMW$G$"$k!%$^$:%0%k!<%W$K$D$$$F@bL@$7$?8e!$$3$NM}M3$K?($l$k!%(B
+
 \begin{itemize}
-\item The ``accepted'' group.  Patches that the development team has
-  submitted to the maintainer of the Infiniband subsystem, and which
-  he has accepted, but which are not present in the snapshot that the
-  tiny repository is based on.  These are ``read only'' patches,
-  present only to transform the tree into a similar state as it is in
-  the upstream maintainer's repository.
-\item The ``rework'' group.  Patches that I have submitted, but that
-  the upstream maintainer has requested modifications to before he
-  will accept them.
-\item The ``pending'' group.  Patches that I have not yet submitted to
-  the upstream maintainer, but which we have finished working on.
-  These will be ``read only'' for a while.  If the upstream maintainer
-  accepts them upon submission, I'll move them to the end of the
-  ``accepted'' group.  If he requests that I modify any, I'll move
-  them to the beginning of the ``rework'' group.
-\item The ``in progress'' group.  Patches that are actively being
-  developed, and should not be submitted anywhere yet.
-\item The ``backport'' group.  Patches that adapt the source tree to
-  older versions of the kernel tree.
-\item The ``do not ship'' group.  Patches that for some reason should
-  never be submitted upstream.  For example, one such patch might
-  change embedded driver identification strings to make it easier to
-  distinguish, in the field, between an out-of-tree version of the
-  driver and a version shipped by a distribution vendor.
+%\item The ``accepted'' group.  Patches that the development team has
+%  submitted to the maintainer of the Infiniband subsystem, and which
+%  he has accepted, but which are not present in the snapshot that the
+%  tiny repository is based on.  These are ``read only'' patches,
+%  present only to transform the tree into a similar state as it is in
+%  the upstream maintainer's repository.
+\item ``accepted''$B%0%k!<%W!%3+H/%A!<%`$,(BInfiniband$B%5%V%7%9%F%`$N%a%s%F%J(B
+      $B$KDs=P$7!$<uM}$5$l$?$,!$>.%j%]%8%H%j$N%Y!<%9$H$J$C$F$$$k%9%J%C%W(B
+      $B%7%g%C%H$K$O$^$@<h$j9~$^$l$F$$$J$$$b$N!%$3$l$i$O%D%j!<$r>eN.%a%s%F(B
+      $B%J$N%j%]%8%H%j$HF1MM$N>uBV$K$9$k$?$a$KB8:_$9$k(B``$BFI$_=P$7$N$_(B''$B$N%Q%C(B
+      $B%A$G$"$k!%(B
+%\item The ``rework'' group.  Patches that I have submitted, but that
+%  the upstream maintainer has requested modifications to before he
+%  will accept them.
+\item ``rework''$B%0%k!<%W!%Ds=P$7$?$,>eN.%a%s%F%J$,<uM}$K@h$@$C$FJQ99$rMW(B
+      $B5a$7$?$b$N!%(B
+%\item The ``pending'' group.  Patches that I have not yet submitted to
+%  the upstream maintainer, but which we have finished working on.
+%  These will be ``read only'' for a while.  If the upstream maintainer
+%  accepts them upon submission, I'll move them to the end of the
+%  ``accepted'' group.  If he requests that I modify any, I'll move
+%  them to the beginning of the ``rework'' group.
+\item ``pending''$B%0%k!<%W!%>eN.%a%s%F%J$K$O$^$@Ds=P$7$F$$$J$$$,!$<j85$G(B
+      $B$N:n6H$O40N;$7$?$b$N!%$3$l$i$O$7$P$i$/$N4V(B``read only''$B$K$J$C$F$*(B
+      $B$j!$>eN.$N%a%s%F%J$XDs=P$7$F<uM}$5$l$?;~$O(B``accepted''$B%0%k!<%W$X0\(B
+      $BF0$5$l$k!%%a%s%F%J$,JQ99$rMW5a$7$?>l9g$O(B``rework''$B%0%k!<%W$X0\F0$5(B
+      $B$l$k!%(B
+%\item The ``in progress'' group.  Patches that are actively being
+%  developed, and should not be submitted anywhere yet.
+\item ``in progress''$B%0%k!<%W!%$3$N%0%k!<%W$K$O!$%"%/%F%#%V$K3+H/$5(B
+      $B$l$F$*$j!$$^$@$I$3$X$bDs=P$5$l$k$Y$-$G$O$J$$%Q%C%A$,4^$^$l$k!%(B
+%\item The ``backport'' group.  Patches that adapt the source tree to
+%  older versions of the kernel tree.
+\item ``backport''$B%0%k!<%W!%%=!<%9$r8E$$%P!<%8%g%s$N%+!<%M%k%D%j!<$XE,9g(B
+      $B$5$;$k%Q%C%A$+$i$J$k!%(B
+%\item The ``do not ship'' group.  Patches that for some reason should
+%  never be submitted upstream.  For example, one such patch might
+%  change embedded driver identification strings to make it easier to
+%  distinguish, in the field, between an out-of-tree version of the
+%  driver and a version shipped by a distribution vendor.
+\item ``do not ship''$B%0%k!<%W!%$J$s$i$+$NM}M3$K$h$C$F7h$7$F>eN.$XDs=P$5$l(B
+      $B$k$Y$-$G$J$$%Q%C%A$+$i$J$k!%Nc$($P!$%D%j!<30$N%I%i%$%P$H%Y%s%@$K$h$C(B
+      $B$FG[I[$5$l$F$$$k%I%i%$%P$r<1JL$7$d$9$/$9$k$?$a$K%I%i%$%P$N<1JLJ8;z(B
+      $BNs$rJQ99$9$k$h$&$J%Q%C%A$,3:Ev$9$k!%(B
 \end{itemize}
 
-Now to return to the reasons for ordering groups of patches in this
-way.  We would like the lowest patches in the stack to be as stable as
-possible, so that we will not need to rework higher patches due to
-changes in context.  Putting patches that will never be changed first
-in the \sfilename{series} file serves this purpose.
+%Now to return to the reasons for ordering groups of patches in this
+%way.  We would like the lowest patches in the stack to be as stable as
+%possible, so that we will not need to rework higher patches due to
+%changes in context.  Putting patches that will never be changed first
+%in the \sfilename{series} file serves this purpose.
+
+$B%Q%C%A$r$3$N$h$&$JJ}K!$G@0M}$9$kM}M3$N@bL@$XLa$m$&!%0lHL$K!$%Q%C%A%9%?%C(B
+$B%/$NDl$K$"$k%Q%C%A$O$J$k$Y$/0BDj$G$"$C$FM_$7$$$H;W$&$b$N$@!%$=$&$G$"$l(B
+$B$P!$%Q%C%A$N%3%s%F%-%9%H$GJQ99$K$h$k:F:n6H$r$;$:$K:Q$`!%(B
+\sfilename{series}$B$K:G=i$KDI2C$9$k%Q%C%A$O7h$7$FJQ99$5$l$J$$$b$N$K$9$k$H(B
+$B$h$$!%(B
 
-We would also like the patches that we know we'll need to modify to be
-applied on top of a source tree that resembles the upstream tree as
-closely as possible.  This is why we keep accepted patches around for
-a while.
+%We would also like the patches that we know we'll need to modify to be
+%applied on top of a source tree that resembles the upstream tree as
+%closely as possible.  This is why we keep accepted patches around for
+%a while.
+
+$B$^$?!$E,MQ$N$?$a$KJQ99$7$J$1$l$P$J$i$J$$%Q%C%A$K$D$$$F$O!$$G$-$k$@$1>eN.(B
+$B$N%D%j!<$K6a$$%=!<%9%D%j!<$KE,MQ$G$-$k$h$&$K$J$C$F$$$FM_$7$$$H9M$($k!%$3(B
+$B$l$,<uM}$5$l$?%Q%C%A$r$7$P$i$/$N4VJ];}$7$F$$$kM}M3$G$"$k!%(B
 
-The ``backport'' and ``do not ship'' patches float at the end of the
-\sfilename{series} file.  The backport patches must be applied on top
-of all other patches, and the ``do not ship'' patches might as well
-stay out of harm's way.
+%The ``backport'' and ``do not ship'' patches float at the end of the
+%\sfilename{series} file.  The backport patches must be applied on top
+%of all other patches, and the ``do not ship'' patches might as well
+%stay out of harm's way.
+
+``backport''$B$H(B``do not ship''$B%Q%C%A$O(B\sfilename{series}$B%U%!%$%k$NKvHx$KCV(B
+$B$+$l$k!%(B``backport''$B%Q%C%A$OB>$N%Q%C%A$9$Y$F$N>e$+$iE,MQ$5$l$J$1$l$P$J$i(B
+$B$J$$$7!$(B``do not ship''$B%Q%C%A$O0BA4$J$H$3$m$KCV$+$l$F$$$J$1$l$P$J$i$J$$!%(B
 
 %\section{Maintaining the patch series}
 \section{$B%Q%C%A%7%j!<%:$r4IM}$9$k(B}
 
-In my work, I use a number of guards to control which patches are to
-be applied.
+%In my work, I use a number of guards to control which patches are to
+%be applied.
+
+$B$3$N:n6H$G$O!$$I$N%Q%C%A$,E,MQ$5$l$k$+@)8f$9$k$?$a$K$$$/$D$+$N%,!<%I$rMQ(B
+$B$$$F$$$k!%(B
 
 \begin{itemize}
-\item ``Accepted'' patches are guarded with \texttt{accepted}.  I
-  enable this guard most of the time.  When I'm applying the patches
-  on top of a tree where the patches are already present, I can turn
-  this patch off, and the patches that follow it will apply cleanly.
-\item Patches that are ``finished'', but not yet submitted, have no
-  guards.  If I'm applying the patch stack to a copy of the upstream
-  tree, I don't need to enable any guards in order to get a reasonably
-  safe source tree.
-\item Those patches that need reworking before being resubmitted are
-  guarded with \texttt{rework}.
-\item For those patches that are still under development, I use
-  \texttt{devel}.
-\item A backport patch may have several guards, one for each version
-  of the kernel to which it applies.  For example, a patch that
-  backports a piece of code to~2.6.9 will have a~\texttt{2.6.9} guard.
+%\item ``Accepted'' patches are guarded with \texttt{accepted}.  I
+%  enable this guard most of the time.  When I'm applying the patches
+%  on top of a tree where the patches are already present, I can turn
+%  this patch off, and the patches that follow it will apply cleanly.
+
+\item ``Accepted''$B%Q%C%A$O(B\texttt{accepted}$B$K$h$C$F%,!<%I$5$l$F$$$k!%I.<T(B
+$B$O$3$N%,!<%I$r$[$\$$$D$bM-8z$K$7$F$$$k!%$9$G$K%Q%C%A$,B8:_$7$F$$$k%D%j!<(B
+$B$N>e$K?7$?$J%Q%C%A$rE,MQ$9$k;~$O!$$3$N%Q%C%A$r%*%U$K$7$F!$8eB3$N%Q%C%A$,(B
+$B%/%j!<%s$KE,MQ$5$l$k$h$&$K$9$k$3$H$,$G$-$k!%(B
+
+%\item Patches that are ``finished'', but not yet submitted, have no
+%  guards.  If I'm applying the patch stack to a copy of the upstream
+%  tree, I don't need to enable any guards in order to get a reasonably
+%  safe source tree.
+
+\item $B40@.$5$l$F$$$k$b$N$N!$$^$@Ds=P$5$l$F$$$J$$%Q%C%A$O%,!<%I$r;}$?$J(B
+      $B$$!%$3$N%Q%C%A%9%?%C%/$r>eN.%D%j!<$N%3%T!<$KE,MQ$9$k>l9g!$%,!<%I$r(B
+      $BA4$/;H$o$:$K==J,0BA4$J%=!<%9%D%j!<$rF@$k$3$H$,$G$-$k!%(B
+
+%\item Those patches that need reworking before being resubmitted are
+%  guarded with \texttt{rework}.
+
+ \item $B:FDs=P$N$?$a$K:n6H$,I,MW$J%Q%C%A$K$O(B\texttt{rework}$B%,!<%I$rMQ$$$k!%(B
+
+%\item For those patches that are still under development, I use
+%  \texttt{devel}.
+
+ \item $B3+H/Cf$N%Q%C%A$K$O(B\texttt{devel}$B%,!<%I$rMQ$$$F$$$k!%(B
+
+%\item A backport patch may have several guards, one for each version
+%  of the kernel to which it applies.  For example, a patch that
+%  backports a piece of code to~2.6.9 will have a~\texttt{2.6.9} guard.
+
+ \item $B%P%C%/%]!<%H%Q%C%A$O%Q%C%A$,E,MQ$5$l$k%+!<%M%k$N%P!<%8%g%s$=$l$>$l(B
+      $B$KBP$7$F%,!<%I$r;}$D$3$H$,$"$k!%Nc$($P!$$"$k%3!<%I$r(B~2.6.9$B$K%P%C%/(B
+      $B%]!<%H$9$k%Q%C%A$O(B~\texttt{2.6.9}$B$H$$$&%,!<%I$r;}$D!%(B
 \end{itemize}
-This variety of guards gives me considerable flexibility in
-qdetermining what kind of source tree I want to end up with.  For most
-situations, the selection of appropriate guards is automated during
-the build process, but I can manually tune the guards to use for less
-common circumstances.
+%This variety of guards gives me considerable flexibility in
+%determining what kind of source tree I want to end up with.  For most
+%situations, the selection of appropriate guards is automated during
+%the build process, but I can manually tune the guards to use for less
+%common circumstances.
+
+$BB?$/$N%,!<%I$rMQ$$$k$3$H$K$h$C$F!$=@Fp$K:n6HBP>]$N%=!<%9%D%j!<$rA*$V$3$H(B
+$B$,$G$-$k!%%S%k%I=hM}Cf$K@5$7$$%,!<%I$r<+F0E*$KA*Br$G$-$k$3$H$,$[$H$s$I$@(B
+$B$,!$FC<l$J>u67$N$?$a$K<j$GA*$V$3$H$b2DG=$G$"$k!%(B
 
 %\subsection{The art of writing backport patches}
 \subsection{$B%P%C%/%]!<%H%Q%C%A$r=q$/5;=Q(B}
 
-Using MQ, writing a backport patch is a simple process.  All such a
-patch has to do is modify a piece of code that uses a kernel feature
-not present in the older version of the kernel, so that the driver
-continues to work correctly under that older version.
+%Using MQ, writing a backport patch is a simple process.  All such a
+%patch has to do is modify a piece of code that uses a kernel feature
+%not present in the older version of the kernel, so that the driver
+%continues to work correctly under that older version.
+
+MQ$B$r;H$C$F%P%C%/%]!<%H%Q%C%A$r=q$/$N$OC1=c$J:n6H$G$"$k!%$=$N$h$&$J%Q%C%A(B
+$B$,$9$Y$-$3$H$O!$8E$$%P!<%8%g%s$N%+!<%M%k$KHw$o$C$F$$$J$$5!G=$r;H$&%3!<%I(B
+$B$rJQ99$7!$8E$$%P!<%8%g%s$N%+!<%M%k$G$b@5$7$/5!G=$7B3$1$k$h$&$K$9$k$3$H$@(B
+$B$1$G$"$k!%(B
+
+%A useful goal when writing a good backport patch is to make your code
+%look as if it was written for the older version of the kernel you're
+%targeting.  The less obtrusive the patch, the easier it will be to
+%understand and maintain.  If you're writing a collection of backport
+%patches to avoid the ``rat's nest'' effect of lots of
+%\texttt{\#ifdef}s (hunks of source code that are only used
+%conditionally) in your code, don't introduce version-dependent
+%\texttt{\#ifdef}s into the patches.  Instead, write several patches,
+%each of which makes unconditional changes, and control their
+%application using guards.
 
-A useful goal when writing a good backport patch is to make your code
-look as if it was written for the older version of the kernel you're
-targeting.  The less obtrusive the patch, the easier it will be to
-understand and maintain.  If you're writing a collection of backport
-patches to avoid the ``rat's nest'' effect of lots of
-\texttt{\#ifdef}s (hunks of source code that are only used
-conditionally) in your code, don't introduce version-dependent
-\texttt{\#ifdef}s into the patches.  Instead, write several patches,
-each of which makes unconditional changes, and control their
-application using guards.
+$B$h$$%P%C%/%]!<%H%Q%C%A$H$O!$$=$N%Q%C%A$K$h$C$F$"$?$+$b%3!<%I$,%?!<%2%C%H(B
+$B$N8E$$%P!<%8%g%s$N%+!<%M%k$K8~$1$F=q$+$l$?$h$&$J>uBV$K$J$k$b$N$G$"$k!%(B
+$BL5M}$N$J$$%Q%C%A$OM}2r$7$d$9$/!$%a%s%F%J%s%9$bMF0W$G$"$k!%(B
+$B%P%C%/%]!<%H%Q%C%A$r$$$/$D$b=q$$$F$$$k$J$i$P!$%3!<%IFb$NBgNL$N(B
+\texttt{\#ifdef}$B$G>r7oE*%3%s%Q%$%k$5$l$k%3!<%I$K$h$k:.Mp$rHr$1$k$Y$-$G$"(B
+$B$k!%$=$N$?$a$K%P!<%8%g%s$K0MB8$7$?(B\texttt{\#ifdef}$B$G$O$J$/!$%,!<%I$K$h$C(B
+$B$F@)8f$5$l$k>r7o%3%s%Q%$%k$K$h$i$J$$JQ99$r2C$($k$Y$-$G$"$k!%(B
 
-There are two reasons to divide backport patches into a distinct
-group, away from the ``regular'' patches whose effects they modify.
-The first is that intermingling the two makes it more difficult to use
-a tool like the \hgext{patchbomb} extension to automate the process of
-submitting the patches to an upstream maintainer.  The second is that
-a backport patch could perturb the context in which a subsequent
-regular patch is applied, making it impossible to apply the regular
-patch cleanly \emph{without} the earlier backport patch already being
-applied.
+%There are two reasons to divide backport patches into a distinct
+%group, away from the ``regular'' patches whose effects they modify.
+%The first is that intermingling the two makes it more difficult to use
+%a tool like the \hgext{patchbomb} extension to automate the process of
+%submitting the patches to an upstream maintainer.  The second is that
+%a backport patch could perturb the context in which a subsequent
+%regular patch is applied, making it impossible to apply the regular
+%patch cleanly \emph{without} the earlier backport patch already being
+%applied.
+
+$B%P%C%/%]!<%H%Q%C%A$rDL>o$NJQ99$r2C$($k%Q%C%A$HJL$N%0%k!<%W$KJ,3d$9$kM}M3(B
+$B$,(B2$B$D$"$k!%Bh0l$NM}M3$O!$(B2$B$D$r:.$<9g$o$;$k$3$H$G!$>eN.$N%a%s%F%J$X%Q%C%A(B
+$B$rDs=P$9$k$?$a$K(B\hgext{patchbomb}$B%(%/%9%F%s%7%g%s$N$h$&$J%D!<%k$r;H$&$N$,(B
+$BFq$7$/$J$k$3$H$G$"$k!%BhFs$NM}M3$O!$%P%C%/%]!<%H%Q%C%A$O!$8eB3$NDL>o%Q%C(B
+$B%A$NE,MQ$5$l$k%3%s%F%-%9%H$rMp$9$3$H$,$"$j!$$=$N$h$&$J>l9g!$DL>o%Q%C%A$O(B
+$B%P%C%/%]!<%H%Q%C%A$J$7$K@5$7$/E,MQ$9$k$3$H$,IT2DG=$K$J$C$F$7$^$&!%(B
 
 %\section{Useful tips for developing with MQ}
 \section{MQ$B$K$h$k3+H/$N(Btips}
@@ -481,81 +570,130 @@
 %\subsection{Organising patches in directories}
 \subsection{$B%G%#%l%/%H%jFb$G%Q%C%A$r4IM}$9$k(B}
 
-If you're working on a substantial project with MQ, it's not difficult
-to accumulate a large number of patches.  For example, I have one
-patch repository that contains over 250 patches.
+%If you're working on a substantial project with MQ, it's not difficult
+%to accumulate a large number of patches.  For example, I have one
+%patch repository that contains over 250 patches.
+
+MQ$B$rMQ$$$FHf3SE*Bg5,LO$J%W%m%8%'%/%H$G:n6H$7$F$$$k>l9g!$BgNL$N%Q%C%A$,C_(B
+$B@Q$9$k$3$H$,>/$J$/$J$$!%Nc$($PI.<T$N$H$3$m$K$O!$(B250$B0J>e$N%Q%C%A$r4^$`%Q%C(B
+$B%A%j%]%8%H%j$,$"$k!%(B
 
-If you can group these patches into separate logical categories, you
-can if you like store them in different directories; MQ has no
-problems with patch names that contain path separators.
+%If you can group these patches into separate logical categories, you
+%can if you like store them in different directories; MQ has no
+%problems with patch names that contain path separators.
+
+$B$b$7$3$l$i$N%Q%C%A$rO@M}E*$J%+%F%4%j$KJ,3d$9$k$3$H$,$G$-!$JL!9$N%G%#%l%/(B
+$B%H%j$K<}MF$7$?$$$H9M$($k$J$i$P!$%Q%C%AL>$K%Q%9%;%Q%l!<%?$r4^$a$F$b(BMQ$B$OLd(B
+$BBj$J$/<h$j07$&$3$H$,$G$-$k!%(B
 
 %\subsection{Viewing the history of a patch}
 \subsection{$B%Q%C%A$N%R%9%H%j$r8+$k(B}
 \label{mq-collab:tips:interdiff}
 
-If you're developing a set of patches over a long time, it's a good
-idea to maintain them in a repository, as discussed in
-section~\ref{sec:mq:repo}.  If you do so, you'll quickly discover that
-using the \hgcmd{diff} command to look at the history of changes to a
-patch is unworkable.  This is in part because you're looking at the
-second derivative of the real code (a diff of a diff), but also
-because MQ adds noise to the process by modifying time stamps and
-directory names when it updates a patch.
+%If you're developing a set of patches over a long time, it's a good
+%idea to maintain them in a repository, as discussed in
+%section~\ref{sec:mq:repo}.  If you do so, you'll quickly discover that
+%using the \hgcmd{diff} command to look at the history of changes to a
+%patch is unworkable.  This is in part because you're looking at the
+%second derivative of the real code (a diff of a diff), but also
+%because MQ adds noise to the process by modifying time stamps and
+%directory names when it updates a patch.
+
+$BD9$$4|4V$K$o$?$C$FB?$/$N%Q%C%A$r:n$C$F$-$?$N$J$i!$(B~\ref{sec:mq:repo}$B@a$G(B
+$B5DO@$7$F$-$?$h$&$K$=$l$i$r%j%]%8%H%j$G4IM}$9$k$N$ONI$$9M$($G$"$k!%$=$&$7(B
+$B$?>l9g!$$9$0$K(B\hgcmd{diff}$B%3%^%s%I$G$O%Q%C%A$N%R%9%H%j$r8+$k$3$H$K;H$($J(B
+$B$$$3$H$K5$$E$/$@$m$&!%$3$l$O<B:]$N%3!<%I$NFs<!E*$JGI@8J*!J(Bdiff$B$N(Bdiff$B!K$r(B
+$B8+$F$$$k$3$H$H!$(BMQ$B$,%Q%C%A$r99?7$9$k;~$K%?%$%`%9%?%s%W$H%G%#%l%/%H%jL>$r(B
+$BJQ99$9$k$3$H$G!$%W%m%;%9$K%N%$%:$r2C$($F$$$k$?$a$G$G$"$k!%(B
 
-However, you can use the \hgext{extdiff} extension, which is bundled
-with Mercurial, to turn a diff of two versions of a patch into
-something readable.  To do this, you will need a third-party package
-called \package{patchutils}~\cite{web:patchutils}.  This provides a
-command named \command{interdiff}, which shows the differences between
-two diffs as a diff.  Used on two versions of the same diff, it
-generates a diff that represents the diff from the first to the second
-version.
+%However, you can use the \hgext{extdiff} extension, which is bundled
+%with Mercurial, to turn a diff of two versions of a patch into
+%something readable.  To do this, you will need a third-party package
+%called \package{patchutils}~\cite{web:patchutils}.  This provides a
+%command named \command{interdiff}, which shows the differences between
+%two diffs as a diff.  Used on two versions of the same diff, it
+%generates a diff that represents the diff from the first to the second
+%version.
 
-You can enable the \hgext{extdiff} extension in the usual way, by
-adding a line to the \rcsection{extensions} section of your \hgrc.
+$B$7$+$7(BMercurial$B$KF1:-$5$l$F$$$k(B\hgext{extdiff}$B%(%/%9%F%s%7%g%s$r;H$$!$(B2$B$D(B
+$B$N%P!<%8%g%s$N%Q%C%A4V$G0UL#$N$"$k:9J,$r<h$k$3$H$,$G$-$k!%$3$N$?$a$K(B
+\package{patchutils}~\cite{web:patchutils}$B$r;H$&I,MW$,$"$k!%$3$N%Q%C%1!<(B
+$B%8$O(B2$B$D$N(Bdiff$B%U%!%$%k4V$N:9J,$r(Bdiff$B$H$7$FI=<($9$k(B\command{interdiff}$B$H$$(B
+$B$&%3%^%s%I$rDs6!$7$F$$$k!%F1$8(Bdiff$B$N0[$J$k%P!<%8%g%s4V$G;HMQ$9$l$P!$A08e(B
+$B$N(Bdiff$B$N4V$N(Bdiff$B$r@8@.$9$k!%(B
+
+%You can enable the \hgext{extdiff} extension in the usual way, by
+%adding a line to the \rcsection{extensions} section of your \hgrc.
+\hgrc$B%U%!%$%k$N(B\rcsection{extensions}$B%;%/%7%g%s$K<!$N9T$rDI2C$9$kDL>o$N(B
+$BJ}K!$G(B\hgext{extdiff}$B$rM-8z$K$G$-$k!%(B
 \begin{codesample2}
   [extensions]
   extdiff =
 \end{codesample2}
-The \command{interdiff} command expects to be passed the names of two
-files, but the \hgext{extdiff} extension passes the program it runs a
-pair of directories, each of which can contain an arbitrary number of
-files.  We thus need a small program that will run \command{interdiff}
-on each pair of files in these two directories.  This program is
-available as \sfilename{hg-interdiff} in the \dirname{examples}
-directory of the source code repository that accompanies this book.
+%The \command{interdiff} command expects to be passed the names of two
+%files, but the \hgext{extdiff} extension passes the program it runs a
+%pair of directories, each of which can contain an arbitrary number of
+%files.  We thus need a small program that will run \command{interdiff}
+%on each pair of files in these two directories.  This program is
+%available as \sfilename{hg-interdiff} in the \dirname{examples}
+%directory of the source code repository that accompanies this book.
+%\excode{hg-interdiff}
+
+\command{interdiff}$B%3%^%s%I$O(B2$B$D$N%U%!%$%kL>$rEO$5$l$k$3$H$rA[Dj$7$F$$$k(B
+$B$,!$(B\hgext{extdiff}$B3HD%$O!$(B2$B$D$N%G%#%l%/%H%j$r0z?t$H$7$F<h$k%3%^%s%I$r5/(B
+$BF0$9$k!%=>$C$F$3$l$i$N(B2$B$D$N%G%#%l%/%H%j$N3F!9$N%U%!%$%k$KBP$7$F(B
+\command{interdiff}$B$r5/F0$9$k>.$5$J%W%m%0%i%`$,I,MW$K$J$k!%$3$NK\$N%=!<%9(B
+$B%3!<%I%j%]%8%H%j%G%#%l%/%H%jFb$N(B\dirname{examples}$B%G%#%l%/%H%j$K$"$k(B
+\sfilename{hg-interdiff}$B$H$$$&%W%m%0%i%`$,$=$l$@!%(B
 \excode{hg-interdiff}
 
-With the \sfilename{hg-interdiff} program in your shell's search path,
-you can run it as follows, from inside an MQ patch directory:
+%With the \sfilename{hg-interdiff} program in your shell's search path,
+%you can run it as follows, from inside an MQ patch directory:
+$B%7%'%k%5!<%A%Q%9$NCf$K(B\sfilename{hg-interdiff}$B$,$"$l$P!$(B MQ$B%Q%C%A%G%#%l%/(B
+$B%H%j$NCf$+$i<!$N$h$&$K5/F0$G$-$k!%(B
+
 \begin{codesample2}
   hg extdiff -p hg-interdiff -r A:B my-change.patch
 \end{codesample2}
-Since you'll probably want to use this long-winded command a lot, you
-can get \hgext{hgext} to make it available as a normal Mercurial
-command, again by editing your \hgrc.
+%Since you'll probably want to use this long-winded command a lot, you
+%can get \hgext{hgext} to make it available as a normal Mercurial
+%command, again by editing your \hgrc.
+$B$3$ND9$$%3%^%s%I$OIQHK$K;H$&$3$H$K$J$k$@$m$&!%$=$3$G(B\hgrc$B$rJT=8(B
+$B$7!$(B\hgext{hgext}$B$GDL>o$N(BMercurial$B%3%^%s%I$N$h$&$K;H$($k$h$&$K$9$k!%(B
 \begin{codesample2}
   [extdiff]
   cmd.interdiff = hg-interdiff
 \end{codesample2}
-This directs \hgext{hgext} to make an \texttt{interdiff} command
-available, so you can now shorten the previous invocation of
-\hgxcmd{extdiff}{extdiff} to something a little more wieldy.
+%This directs \hgext{hgext} to make an \texttt{interdiff} command
+%available, so you can now shorten the previous invocation of
+%\hgxcmd{extdiff}{extdiff} to something a little more wieldy.
+$B$3$l$O(B\hgext{hgext}$B$K(B\texttt{interdiff}$B%3%^%s%I$,MxMQ2DG=$G$"$k$3$H$r;X(B
+$B<($9$k$?$a!$0JA0$N(B\hgxcmd{extdiff}{extdiff}$B$N5/F0$r<c434JC1$K$G$-$k!%(B
 \begin{codesample2}
   hg interdiff -r A:B my-change.patch
 \end{codesample2}
 
 \begin{note}
-  The \command{interdiff} command works well only if the underlying
-  files against which versions of a patch are generated remain the
-  same.  If you create a patch, modify the underlying files, and then
-  regenerate the patch, \command{interdiff} may not produce useful
-  output.
+%  The \command{interdiff} command works well only if the underlying
+%  files against which versions of a patch are generated remain the
+%  same.  If you create a patch, modify the underlying files, and then
+%  regenerate the patch, \command{interdiff} may not produce useful
+%  output.
+
+\command{interdiff}$B%3%^%s%I$O!$%Q%C%A$N%P!<%8%g%s$,@8@.$5$l$?85$N%U%!%$%k(B
+$B$,F10l$KJ]$?$l$F$$$k>l9g$K8B$C$F@5$7$/F0$/!%%Q%C%A$r:n@.$7$F$+$i85$N%U%!(B
+$B%$%k$rJQ99$7!$%Q%C%A$r:F@8@.$7$?>l9g$O(B\command{interdiff}$B$OM-MQ$J:9J,$r=P(B
+$BNO$7$J$$$+$b$7$l$J$$!%(B
+
 \end{note}
 
-The \hgext{extdiff} extension is useful for more than merely improving
-the presentation of MQ~patches.  To read more about it, go to
-section~\ref{sec:hgext:extdiff}.
+%The \hgext{extdiff} extension is useful for more than merely improving
+%the presentation of MQ~patches.  To read more about it, go to
+%section~\ref{sec:hgext:extdiff}.
+
+\hgext{extdiff}$B%(%/%9%F%s%7%g%s$O(BMQ$B%Q%C%A$NI=8=$r2~A1$9$k0J>e$N$3$H$r$9(B
+$B$k!%$3$N%(%/%9%F%s%7%g%s$K$D$$$F99$KCN$j$?$$;~$O(B\ref{sec:hgext:extdiff}$B%;(B
+$B%/%7%g%s$r;2>H$5$l$?$$!%(B
 
 %%% Local Variables:
 %%% mode: yatex