# HG changeset patch
# User Yoshiki Yazawa <yaz@cc.rim.or.jp>
# Date 1206639479 -32400
# Node ID e03366f4d1e5bec733fc82e7599d9bba448a6b1f
# Parent  a8269a1b91647c029546aa1e7364ec949504a604
more mq.tex. in the mid of a paragraph, but I'm feeling tired.

diff -r a8269a1b9164 -r e03366f4d1e5 ja/mq.tex
--- 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{パッチ管理の問題}
 \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.
+
+よくあるシナリオ：ソースからソフトウェアパッケージをインストールする必要
+がある．しかしパッケージを使う前にソースから直すべきバグを見つけた．変更
+を加えて，暫くパッケージのことは忘れている．数ヶ月後，新しいバージョンを
+インストールすることになった．もし新しいバージョンが，依然としてそのバグ
+を持っていた場合，修正を古いソースから抽出して，新しいバージョンに適用し
+なければならない．これは退屈でしかも間違いやすい仕事だ．
+
+%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.
+これがパッチ管理問題のシンプルな例である．もしあなたが変更できない上流の
+ソースツリーがあれば，アップストリームのツリーの上でローカルな変更をしな
+ければならない．あなたはアップストリームソースに適用できるようにきっとこ
+の変更を分離しておきたいと思うはずだ．
+
+%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.
+パッチ管理問題はいろいろな状況で起こる．おそらく最も明らかなのは，オープ
+ンソースソフトウェアプロジェクトのユーザが，プロジェクトのメンテナにバグ
+フィックスや新機能をパッチの形で貢献することであろう．
 
-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.
+
+オープンソフトウェアを含むオペレーティングシステムの配布者は，配布するパッ
+ケージが彼らの環境で正しくビルドできるようにパッケージへ変更を加えること
+が多い．
 
 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.
 
+もしいくつかの変更を維持しているなら，標準の\command{diff}コマンドと
+\command{patch}コマンドを使って単一のパッチを管理するのが簡単だ．（これ
+らのツールについては~\ref{sec:mq:patch}の節を参照．）
+
+変更の数が増えてくると，単一のバグフィックスだけを含む個別のパッチの集合
+として管理することが現実味を帯びてくる．（それぞれのパッチは複数のファイ
+ルを変更するかもしれないが，目的は1つきりである．）
+
+
+
 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