# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1259771168 -32400
# Node ID d1f676a6a4b36fd694b4a0223778213f2dbdc7d3
# Parent  b775f963b18c7833bbc01c1e148193350229b537
update mq chapter.
propagate ef53d025f410.

diff -r b775f963b18c -r d1f676a6a4b3 ja/examples/ch11-qdelete.convert.lxo
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ja/examples/ch11-qdelete.convert.lxo	Thu Dec 03 01:26:08 2009 +0900
@@ -0,0 +1,13 @@
+<!-- BEGIN ch11/qdelete.convert -->
+<screen><prompt>$</prompt> <userinput>hg qnew good.patch</userinput>
+<prompt>$</prompt> <userinput>echo a &gt; a</userinput>
+<prompt>$</prompt> <userinput>hg add a</userinput>
+<prompt>$</prompt> <userinput>hg qrefresh -m 'Good change'</userinput>
+<prompt>$</prompt> <userinput>hg qfinish tip</userinput>
+<prompt>$</prompt> <userinput>hg qapplied</userinput>
+<prompt>$</prompt> <userinput>hg tip --style=compact</userinput>
+0[tip]   cc3acb068439   2009-08-16 17:04 +0000   bos
+  Good change
+
+</screen>
+<!-- END ch11/qdelete.convert -->
diff -r b775f963b18c -r d1f676a6a4b3 ja/examples/ch11-qdelete.go.lxo
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ja/examples/ch11-qdelete.go.lxo	Thu Dec 03 01:26:08 2009 +0900
@@ -0,0 +1,15 @@
+<!-- BEGIN ch11/qdelete.go -->
+<screen><prompt>$</prompt> <userinput>hg init myrepo</userinput>
+<prompt>$</prompt> <userinput>cd myrepo</userinput>
+<prompt>$</prompt> <userinput>hg qinit</userinput>
+<prompt>$</prompt> <userinput>hg qnew bad.patch</userinput>
+<prompt>$</prompt> <userinput>echo a &gt; a</userinput>
+<prompt>$</prompt> <userinput>hg add a</userinput>
+<prompt>$</prompt> <userinput>hg qrefresh</userinput>
+<prompt>$</prompt> <userinput>hg qdelete bad.patch</userinput>
+abort: cannot delete applied patch bad.patch
+<prompt>$</prompt> <userinput>hg qpop</userinput>
+patch queue now empty
+<prompt>$</prompt> <userinput>hg qdelete bad.patch</userinput>
+</screen>
+<!-- END ch11/qdelete.go -->
diff -r b775f963b18c -r d1f676a6a4b3 ja/examples/ch11-qdelete.import.lxo
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ja/examples/ch11-qdelete.import.lxo	Thu Dec 03 01:26:08 2009 +0900
@@ -0,0 +1,6 @@
+<!-- BEGIN ch11/qdelete.import -->
+<screen><prompt>$</prompt> <userinput>hg qimport -r tip</userinput>
+<prompt>$</prompt> <userinput>hg qapplied</userinput>
+0.diff
+</screen>
+<!-- END ch11/qdelete.import -->
diff -r b775f963b18c -r d1f676a6a4b3 ja/hook.tex
--- a/ja/hook.tex	Tue Sep 15 22:32:03 2009 +0900
+++ b/ja/hook.tex	Thu Dec 03 01:26:08 2009 +0900
@@ -290,154 +290,6 @@
 スできなければリジェクトを行う．ユーザがこのフィルタサーバからのみpullを
 行うのであれば，全ての変更は自動的に全て検査されていることになる．
 
-%\section{Care with \texttt{pretxn} hooks in a shared-access repository}
-\section{共有アクセスリポジトリで\texttt{pretxn}フックを使う}
-
-%If you want to use hooks to do some automated work in a repository
-%that a number of people have shared access to, you need to be careful
-%in how you do this.
-
-複数のユーザが共有アクセスを行うリポジトリで，自動化された作業を行うため
-にフックを使用したいなら，どのように行うか注意深く考える必要がある．
-
-%Mercurial only locks a repository when it is writing to the
-%repository, and only the parts of Mercurial that write to the
-%repository pay attention to locks.  Write locks are necessary to
-%prevent multiple simultaneous writers from scribbling on each other's
-%work, corrupting the repository.
-
-Mercurialはリポジトリに書き込みを行うときにだけリポジトリをロックする．
-またMercurialの書き込みを行う部分のみがロックを考慮する．書き込みロック
-は，複数の同時書き込みが他の変更を上書きし，リポジトリを破損するのを防ぐ．
-
-%Because Mercurial is careful with the order in which it reads and
-%writes data, it does not need to acquire a lock when it wants to read
-%data from the repository.  The parts of Mercurial that read from the
-%repository never pay attention to locks.  This lockless reading scheme
-%greatly increases performance and concurrency.
-
-Mercurialはデータの読み書きの順序を注意深く行うため，リポジトリからのデー
-タ読み出しの際にロックを取得する必要がない． Mercurialのリポジトリから読
-み出しを行う部分は，ロックを全く気にする必要がない．このロックなし読み出
-しによって，同時実行性と性能を大幅に高めている．
-
-%With great performance comes a trade-off, though, one which has the
-%potential to cause you trouble unless you're aware of it.  To describe
-%this requires a little detail about how Mercurial adds changesets to a
-%repository and reads those changes.
-
-しかしながらこの高性能はそれを知らなければ問題を引き起こすあるトレードオ
-フをももたらす．これを説明するために，Mercurialがどのようにチェンジセット
-をリポジトリに追加し，それらを読み出すかの詳細に触れなければならない．
-
-%When Mercurial \emph{writes} metadata, it writes it straight into the
-%destination file.  It writes file data first, then manifest data
-%(which contains pointers to the new file data), then changelog data
-%(which contains pointers to the new manifest data).  Before the first
-%write to each file, it stores a record of where the end of the file
-%was in its transaction log.  If the transaction must be rolled back,
-%Mercurial simply truncates each file back to the size it was before the
-%transaction began.
-
-Mercurialはメタデータを\emph{書き込む}とき，直接目的のファイルに書き込み
-する．Mercurialはまずファイルデータを書き込み，次いで（新しいファイルデー
-タの場所を示すポインタを含む）マニフェストデータを書き込む．そして（新し
-いマニフェストデータの場所を示すポインタを含む）チェンジログデータを書き
-込む．各々のファイルへの最初の書き込みの前に，ファイルの末尾のレコードを
-トランザクションログに保存する．トランザクションがロールバックされる場合
-は，Mercurialは各々のファイルをトランザクションが始まる前のサイズに切り詰
-める．
-
-%When Mercurial \emph{reads} metadata, it reads the changelog first,
-%then everything else.  Since a reader will only access parts of the
-%manifest or file metadata that it can see in the changelog, it can
-%never see partially written data.
-
-Mercurialはメタデータを\emph{読む}時にまずチェンジログを読み，次いで残り
-の部分を読む．リーダはチェンジログに現れるマニフェストの一部またはファイ
-ルメタデータの一部にのみアクセスするため，部分的に書かれたデータを見るこ
-とはできない．
-
-%Some controlling hooks (\hook{pretxncommit} and
-%\hook{pretxnchangegroup}) run when a transaction is almost complete.
-%All of the metadata has been written, but Mercurial can still roll the
-%transaction back and cause the newly-written data to disappear.
-
-いくつかの制御フック（\hook{pretxncommit}と\hook{pretxnchangegroup}）はト
-ランザクションがほぼ完了した時に実行される．すべてのメタデータが書き込ま
-れるが，この時点でもMercurialはトランザクションを元に戻すことができ，その
-場合は新しく書かれたデータは消失する．
-
-%If one of these hooks runs for long, it opens a window of time during
-%which a reader can see the metadata for changesets that are not yet
-%permanent, and should not be thought of as ``really there''.  The
-%longer the hook runs, the longer that window is open.
-
-これらのフックのうち1つが長時間にわたって実行されていると，リーダがチェン
-ジセットのメタデータを読むことのできるタイムウィンドウが開く．このチェン
-ジセットはまだ永続的なものになっておらず，従って実在すると考えるべきでは
-ないものである．フックが実行されている時間が長くなればなるほど，タイムウィ
-ンドウが開く時間も長くなる．
-
-%\subsection{The problem illustrated}
-\subsection{問題の詳細}
-
-%In principle, a good use for the \hook{pretxnchangegroup} hook would
-%be to automatically build and test incoming changes before they are
-%accepted into a central repository.  This could let you guarantee that
-%nobody can push changes to this repository that ``break the build''.
-%But if a client can pull changes while they're being tested, the
-%usefulness of the test is zero; an unsuspecting someone can pull
-%untested changes, potentially breaking their build.
-
-実用における\hook{pretxnchangegroup}フックの良い使用法としては，到着した
-変更が中央のリポジトリに取り込まれる前に自動でビルドとテストを行うことが
-考えられる．これにより，ビルドを妨げる変更は誰もリポジトリにpushできない
-ことが確実になる．クライアントがテスト中に変更をpullすることができれば，
-このテストの有用性はゼロになってしまう．疑いを持たずに誰かがテストされて
-いない変更をpullできるのであれば，彼らのビルドは失敗する可能性がある．
-
-%The safest technological answer to this challenge is to set up such a
-%``gatekeeper'' repository as \emph{unidirectional}.  Let it take
-%changes pushed in from the outside, but do not allow anyone to pull
-%changes from it (use the \hook{preoutgoing} hook to lock it down).
-%Configure a \hook{changegroup} hook so that if a build or test
-%succeeds, the hook will push the new changes out to another repository
-%that people \emph{can} pull from.
-
-この問題への技術的に最も安全な回答は，``門番''リポジトリを\emph{一方向}に
-設定することである．リポジトリを外部からpushされた変更を受け取るが，誰も
-pullできないように設定する（\hook{preoutgoing}フックを使ってリポジトリを
-ロックする）．\hook{changegroup}フックを設定し，ビルドやテストが成功した
-ときに限って，フックが新たな変更をユーザのpull\emph{できる}別のリポジト
-リにpushするようにする．
-
-%In practice, putting a centralised bottleneck like this in place is
-%not often a good idea, and transaction visibility has nothing to do
-%with the problem.  As the size of a project---and the time it takes to
-%build and test---grows, you rapidly run into a wall with this ``try
-%before you buy'' approach, where you have more changesets to test than
-%time in which to deal with them.  The inevitable result is frustration
-%on the part of all involved.
-
-実際上は，このように集中したボトルネックを置くことは良い考えとは言えず，
-トランザクションの可視性は全くない．プロジェクトのサイズおよびビルドとテ
-ストに要する時間が増加するに従って，このような``事前に試す''手法は壁に突
-き当たる．テストに使える時間で捌き切れないほどのチェンジセットを試さなけ
-ればならなくなるからである．フラストレーションが貯るのは避けられないだろ
-う．
-
-%An approach that scales better is to get people to build and test
-%before they push, then run automated builds and tests centrally
-%\emph{after} a push, to be sure all is well.  The advantage of this
-%approach is that it does not impose a limit on the rate at which the
-%repository can accept changes.
-
-よりスケールする手法は，開発者にpush前のビルドとテストをさせることであ
-る．中央で自動によるビルドとテストを行うのは，push\emph{後}に，全てに問題
-がないことを確認するために行う．このアプローチの利点はリポジトリが変更を
-受け入れるペースに何も制限を課さないことである．
-
 %\section{A short tutorial on using hooks}
 \section{フックの使用法}
 \label{sec:hook:simple}
diff -r b775f963b18c -r d1f676a6a4b3 ja/mq.tex
--- a/ja/mq.tex	Tue Sep 15 22:32:03 2009 +0900
+++ b/ja/mq.tex	Thu Dec 03 01:26:08 2009 +0900
@@ -190,8 +190,8 @@
 %extension that he called Mercurial Queues, which added quilt-like
 %behaviour to Mercurial.
 
-2005年の中頃Chris Masonは，quiltの機能を取り入れて，Mercurialにquiltのよ
-うな動作を追加するMercurial Queuesというエクステンションを書いた．
+2005年の中頃，Chris Masonは，quiltの機能を取り入れて，Mercurialにquiltの
+ような動作を追加するMercurial Queuesというエクステンションを書いた．
 
 %The key difference between quilt and MQ is that quilt knows nothing
 %about revision control systems, while MQ is \emph{integrated} into
@@ -1031,22 +1031,13 @@
 い．大抵の場合，\sfilename{.rej}ファイルを見てターゲットファイルを編集
 し，リジェクトされたhunkを手で適用することになる．
 
-%If you're feeling adventurous, Neil Brown, a Linux kernel hacker,
-%wrote a tool called \command{wiggle}~\cite{web:wiggle}, which is more
-%vigorous than \command{patch} in its attempts to make a patch apply.
-
-冒険が好きなら，Linux kernerハッカーのNeil Brownが書いた
-\command{wiggle}~\cite{web:wiggle}を試してみると良い．このコマンドは
-\command{patch}よりも精力的にパッチの適用を試みる．
+%A Linux kernel hacker, Chris Mason (the author of Mercurial Queues),
+%wrote a tool called \command{mpatch}~\cite{web:mpatch}, which takes a
+%simple approach to automating the application of hunks rejected by
+%\command{patch}. The \command{mpatch} command can help with four common
+%reasons that a hunk may be rejected:
 
-%Another Linux kernel hacker, Chris Mason (the author of Mercurial
-%Queues), wrote a similar tool called
-%\command{mpatch}~\cite{web:mpatch}, which takes a simple approach to
-%automating the application of hunks rejected by \command{patch}.  The
-%\command{mpatch} command can help with four common reasons that a hunk
-%may be rejected:
-
-別のLinux kernerハッカー Chris Mason（Mercurial Queuesの作者でもある．）
+Linux kernerハッカー Chris Mason（Mercurial Queuesの作者でもある．）
 は\command{mpatch}~\cite{web:mpatch}というツールを書いた．このコマンドは
 \command{patch}コマンドでリジェクトされたhunkの適用を自動化す
 る．\command{mpatch}コマンドは，hunkがリジェクトされる主な原因4つに対応
@@ -1067,17 +1058,79 @@
       する
 \end{itemize}
 
-%If you use \command{wiggle} or \command{mpatch}, you should be doubly
-%careful to check your results when you're done.  In fact,
-%\command{mpatch} enforces this method of double-checking the tool's
+%If you use \command{mpatch}, you should be doubly careful to
+%check your results when you're done.  In fact, \command{mpatch}
+%enforces this method of double-checking the tool's
 %output, by automatically dropping you into a merge program when it has
 %done its job, so that you can verify its work and finish off any
 %remaining merges.
 
-\command{wiggle}または\command{mpatch}を使用した場合は，結果に細心の注意
-が必要である．実際には\command{mpatch}はツールの出力で二重チェックを強制
-し，動作が終ると自動的にマージプログラムを起動する．これによって作業を確
-認し，マージを完了することができる．
+\command{mpatch}を使用した場合は，結果に細心の注意が必要である．実際には
+\command{mpatch}はツールの出力で二重チェックを強制し，動作が終ると自動的
+にマージプログラムを起動する．これによって作業を確認し，必要なマージを完
+了することができる．
+
+
+%\section{More on patch management}
+\section{さらなるパッチ管理}
+
+%As you grow familiar with MQ, you will find yourself wanting
+%to perform other kinds of patch management operations.
+
+MQに慣れるに従って，別の方法でもパッチ管理をしたくなるだろう．
+
+%\subsection{Deleting unwanted patches}
+\subsection{不要なパッチを消去する}
+
+%If you want to get rid of a patch, use the \command{qdelete} command to
+%delete the patch file and remove its entry from the patch series.  If
+%you try to delete a patch that is still applied, \command{qdelete} will
+%refuse.
+
+パッチを消去するには，\command{qdelete}コマンドを用いて，パッチファイルの
+消去とパッチエントリのパッチシリーズからの抹消を行う．\command{qdelete}は
+適用中のパッチは消去しない．
+
+% &interaction.ch11-qdelete.go;
+\interaction{ch11-qdelete.go}
+
+%\subsection{Converting to and from permanent revisions}
+\subsection{永続的なリビジョンとの相互変換}
+
+%Once you're done working on a patch and want to turn it into a permanent
+%changeset, use the \hgxopt{mq}{qdelete}{-r} command.  Pass a revision to
+%the \option{-r} option to identify the patch that you want to turn into
+%a regular changeset; this patch must already be applied.
+
+パッチでの作業が終り，これを永続的なチェンジセットへ変換したい場合は，
+\hgxopt{mq}{qdelete}{-r}コマンドを用いる．\option{-r}オプションにリビジョ
+ンを渡し，どのパッチを通常のチェンジセットに変換したいのか指定する．変換
+対象のパッチはすでに適用されていなければならない．
+
+%&interaction.ch11-qdelete.convert;
+\interaction{ch11-qdelete.convert}
+
+%It is also possible to turn an existing changeset into a patch, by
+%passing the \option{-r} option to \command{qimport}.
+
+\command{qimport}コマンドに\option{-r}オプションを渡して，すでに存在する
+チェンジセットをパッチに変換することもできる．
+
+%&interaction.ch11-qdelete.import;
+\interaction{ch11-qdelete.import}
+
+%Note that it only makes sense to convert a changeset into a patch if you
+%have not propagated that changeset into any other repositories.  The
+%imported changeset's ID will change every time you refresh the patch,
+%which will make Mercurial treat it as unrelated to the original
+%changeset if you have pushed it somewhere else.
+
+チェンジセットからパッチへの変換が意味を持つのは，チェンジセットをまだ他
+のリポジトリに波及させていない場合に限られる．Mercurialはパッチに変換した
+チェンジセットを元のチェンジセットとは無関係なものとして扱うため，パッチ
+をリフレッシュする度にチェンジセットIDは変わる．すでに別のリポジトリにチェ
+ンジセットをプッシュしているならば，これらのIDは相違してしまう．
+
 
 %\section{Getting the best performance out of MQ}
 \section{MQを最大限に活用する}
@@ -1085,7 +1138,7 @@
 
 %MQ is very efficient at handling a large number of patches.  I ran
 %some performance experiments in mid-2006 for a talk that I gave at the
-%2006 EuroPython conference~\cite{web:europython}.  I used as my data
+%2006 EuroPython conference.  I used as my data
 %set the Linux 2.6.17-mm1 patch series, which consists of 1,738
 %patches.  I applied these on top of a Linux kernel repository
 %containing all 27,472 revisions between Linux 2.6.12-rc2 and Linux