changeset 326:e03366f4d1e5

more mq.tex. in the mid of a paragraph, but I'm feeling tired.

--- a/ja/mq.tex	Fri Mar 28 02:11:02 2008 +0900
+++ b/ja/mq.tex	Fri Mar 28 02:37:59 2008 +0900
@@ -6,43 +6,77 @@
 \section{$B%Q%C%A4IM}$NLdBj(B}
 \label{sec:mq:patch-mgmt}
 
-Here is a common scenario: you need to install a software package from
-source, but you find a bug that you must fix in the source before you
-can start using the package.  You make your changes, forget about the
-package for a while, and a few months later you need to upgrade to a
-newer version of the package.  If the newer version of the package
-still has the bug, you must extract your fix from the older source
-tree and apply it against the newer version.  This is a tedious task,
-and it's easy to make mistakes.
+%Here is a common scenario: you need to install a software package from
+%source, but you find a bug that you must fix in the source before you
+%can start using the package.  You make your changes, forget about the
+%package for a while, and a few months later you need to upgrade to a
+%newer version of the package.  If the newer version of the package
+%still has the bug, you must extract your fix from the older source
+%tree and apply it against the newer version.  This is a tedious task,
+%and it's easy to make mistakes.
+
+$B$h$/$"$k%7%J%j%*!'%=!<%9$+$i%=%U%H%&%'%"%Q%C%1!<%8$r%$%s%9%H!<%k$9$kI,MW(B
+$B$,$"$k!%$7$+$7%Q%C%1!<%8$r;H$&A0$K%=!<%9$+$iD>$9$Y$-%P%0$r8+$D$1$?!%JQ99(B
+$B$r2C$($F!$;C$/%Q%C%1!<%8$N$3$H$OK:$l$F$$$k!%?t%v7n8e!$?7$7$$%P!<%8%g%s$r(B
+$B%$%s%9%H!<%k$9$k$3$H$K$J$C$?!%$b$7?7$7$$%P!<%8%g%s$,!$0MA3$H$7$F$=$N%P%0(B
+$B$r;}$C$F$$$?>l9g!$=$@5$r8E$$%=!<%9$+$iCj=P$7$F!$?7$7$$%P!<%8%g%s$KE,MQ$7(B
+$B$J$1$l$P$J$i$J$$!%$3$l$OB`6~$G$7$+$b4V0c$$$d$9$$;E;v$@!%(B
+
+%This is a simple case of the ``patch management'' problem.  You have
+%an ``upstream'' source tree that you can't change; you need to make
+%some local changes on top of the upstream tree; and you'd like to be
+%able to keep those changes separate, so that you can apply them to
+%newer versions of the upstream source.
 
-This is a simple case of the ``patch management'' problem.  You have
-an ``upstream'' source tree that you can't change; you need to make
-some local changes on top of the upstream tree; and you'd like to be
-able to keep those changes separate, so that you can apply them to
-newer versions of the upstream source.
+$B$3$l$,%Q%C%A4IM}LdBj$N%7%s%W%k$JNc$G$"$k!%$b$7$"$J$?$,JQ99$G$-$J$$>eN.$N(B
+$B%=!<%9%D%j!<$,$"$l$P!$%"%C%W%9%H%j!<%`$N%D%j!<$N>e$G%m!<%+%k$JJQ99$r$7$J(B
+$B$1$l$P$J$i$J$$!%$"$J$?$O%"%C%W%9%H%j!<%`%=!<%9$KE,MQ$G$-$k$h$&$K$-$C$H$3(B
+$B$NJQ99$rJ,N%$7$F$*$-$?$$$H;W$&$O$:$@!%(B
+
+%The patch management problem arises in many situations.  Probably the
+%most visible is that a user of an open source software project will
+%contribute a bug fix or new feature to the project's maintainers in the
+%form of a patch.
 
-The patch management problem arises in many situations.  Probably the
-most visible is that a user of an open source software project will
-contribute a bug fix or new feature to the project's maintainers in the
-form of a patch.
+$B%Q%C%A4IM}LdBj$O$$$m$$$m$J>u67$G5/$3$k!%$*$=$i$/:G$bL@$i$+$J$N$O!$%*!<%W(B
+$B%s%=!<%9%=%U%H%&%'%"%W%m%8%'%/%H$N%f!<%6$,!$%W%m%8%'%/%H$N%a%s%F%J$K%P%0(B
+$B%U%#%C%/%9$d?75!G=$r%Q%C%A$N7A$G9W8%$9$k$3$H$G$"$m$&!%(B
 
-Distributors of operating systems that include open source software
-often need to make changes to the packages they distribute so that
-they will build properly in their environments.
+%Distributors of operating systems that include open source software
+%often need to make changes to the packages they distribute so that
+%they will build properly in their environments.
+
+$B%*!<%W%s%=%U%H%&%'%"$r4^$`%*%Z%l!<%F%#%s%0%7%9%F%`$NG[I[<T$O!$G[I[$9$k%Q%C(B
+$B%1!<%8$,H`$i$N4D6-$G@5$7$/%S%k%I$G$-$k$h$&$K%Q%C%1!<%8$XJQ99$r2C$($k$3$H(B
+$B$,B?$$!%(B
 
 When you have few changes to maintain, it is easy to manage a single
 patch using the standard \command{diff} and \command{patch} programs
 (see section~\ref{sec:mq:patch} for a discussion of these tools).
+
 Once the number of changes grows, it starts to make sense to maintain
 patches as discrete ``chunks of work,'' so that for example a single
 patch will contain only one bug fix (the patch might modify several
-files, but it's doing ``only one thing''), and you may have a number
+files, but it's doing ``only one thing''),
+
+
+and you may have a number
 of such patches for different bugs you need fixed and local changes
 you require.  In this situation, if you submit a bug fix patch to the
 upstream maintainers of a package and they include your fix in a
 subsequent release, you can simply drop that single patch when you're
 updating to the newer release.
 
+$B$b$7$$$/$D$+$NJQ99$r0];}$7$F$$$k$J$i!$I8=`$N(B\command{diff}$B%3%^%s%I$H(B
+\command{patch}$B%3%^%s%I$r;H$C$FC10l$N%Q%C%A$r4IM}$9$k$N$,4JC1$@!%!J$3$l(B
+$B$i$N%D!<%k$K$D$$$F$O(B~\ref{sec:mq:patch}$B$N@a$r;2>H!%!K(B
+
+$BJQ99$N?t$,A}$($F$/$k$H!$C10l$N%P%0%U%#%C%/%9$@$1$r4^$`8DJL$N%Q%C%A$N=89g(B
+$B$H$7$F4IM}$9$k$3$H$,8=<BL#$rBS$S$F$/$k!%!J$=$l$>$l$N%Q%C%A$OJ#?t$N%U%!%$(B
+$B%k$rJQ99$9$k$+$b$7$l$J$$$,!$L\E*$O(B1$B$D$-$j$G$"$k!%!K(B
+
+
+
 Maintaining a single patch against an upstream tree is a little
 tedious and error-prone, but not difficult.  However, the complexity
 of the problem grows rapidly as the number of patches you have to