Mercurial > hgbook

--- /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 -->
--- /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 -->
--- /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 -->
--- 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 @@
 $B%9$G$-$J$1$l$P%j%8%'%/%H$r9T$&!%%f!<%6$,$3$N%U%#%k%?%5!<%P$+$i$N$_(Bpull$B$r(B
 $B9T$&$N$G$"$l$P!$A4$F$NJQ99$O<+F0E*$KA4$F8!::$5$l$F$$$k$3$H$K$J$k!%(B

-%\section{Care with \texttt{pretxn} hooks in a shared-access repository}
-\section{$B6&M-%"%/%;%9%j%]%8%H%j$G(B\texttt{pretxn}$B%U%C%/$r;H$&(B}
-
-%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.
-
-$BJ#?t$N%f!<%6$,6&M-%"%/%;%9$r9T$&%j%]%8%H%j$G!$<+F02=$5$l$?:n6H$r9T$&$?$a(B
-$B$K%U%C%/$r;HMQ$7$?$$$J$i!$$I$N$h$&$K9T$&$+Cm0U?<$/9M$($kI,MW$,$"$k!%(B
-
-%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$B$O%j%]%8%H%j$K=q$-9~$_$r9T$&$H$-$K$@$1%j%]%8%H%j$r%m%C%/$9$k!%(B
-$B$^$?(BMercurial$B$N=q$-9~$_$r9T$&ItJ,$N$_$,%m%C%/$r9MN8$9$k!%=q$-9~$_%m%C%/(B
-$B$O!$J#?t$NF1;~=q$-9~$_$,B>$NJQ99$r>e=q$-$7!$%j%]%8%H%j$rGKB;$9$k$N$rKI$0!%(B
-
-%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$B$O%G!<%?$NFI$_=q$-$N=g=x$rCm0U?<$/9T$&$?$a!$%j%]%8%H%j$+$i$N%G!<(B
-$B%?FI$_=P$7$N:]$K%m%C%/$r<hF@$9$kI,MW$,$J$$!%(B Mercurial$B$N%j%]%8%H%j$+$iFI(B
-$B$_=P$7$r9T$&ItJ,$O!$%m%C%/$rA4$/5$$K$9$kI,MW$,$J$$!%$3$N%m%C%/$J$7FI$_=P(B
-$B$7$K$h$C$F!$F1;~<B9T@-$H@-G=$rBgI}$K9b$a$F$$$k!%(B
-
-%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.
-
-$B$7$+$7$J$,$i$3$N9b@-G=$O$=$l$rCN$i$J$1$l$PLdBj$r0z$-5/$3$9$"$k%H%l!<%I%*(B
-$B%U$r$b$b$?$i$9!%$3$l$r@bL@$9$k$?$a$K!$(BMercurial$B$,$I$N$h$&$K%A%'%s%8%;%C%H(B
-$B$r%j%]%8%H%j$KDI2C$7!$$=$l$i$rFI$_=P$9$+$N>\:Y$K?($l$J$1$l$P$J$i$J$$!%(B
-
-%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$B$O%a%?%G!<%?$r(B\emph{$B=q$-9~$`(B}$B$H$-!$D>@\L\E*$N%U%!%$%k$K=q$-9~$_(B
-$B$9$k!%(BMercurial$B$O$^$:%U%!%$%k%G!<%?$r=q$-9~$_!$<!$$$G!J?7$7$$%U%!%$%k%G!<(B
-$B%?$N>l=j$r<($9%]%$%s%?$r4^$`!K%^%K%U%'%9%H%G!<%?$r=q$-9~$`!%$=$7$F!J?7$7(B
-$B$$%^%K%U%'%9%H%G!<%?$N>l=j$r<($9%]%$%s%?$r4^$`!K%A%'%s%8%m%0%G!<%?$r=q$-(B
-$B9~$`!%3F!9$N%U%!%$%k$X$N:G=i$N=q$-9~$_$NA0$K!$%U%!%$%k$NKvHx$N%l%3!<%I$r(B
-$B%H%i%s%6%/%7%g%s%m%0$KJ]B8$9$k!%%H%i%s%6%/%7%g%s$,%m!<%k%P%C%/$5$l$k>l9g(B
-$B$O!$(BMercurial$B$O3F!9$N%U%!%$%k$r%H%i%s%6%/%7%g%s$,;O$^$kA0$N%5%$%:$K@Z$j5M(B
-$B$a$k!%(B
-
-%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$B$O%a%?%G!<%?$r(B\emph{$BFI$`(B}$B;~$K$^$:%A%'%s%8%m%0$rFI$_!$<!$$$G;D$j(B
-$B$NItJ,$rFI$`!%%j!<%@$O%A%'%s%8%m%0$K8=$l$k%^%K%U%'%9%H$N0lIt$^$?$O%U%!%$(B
-$B%k%a%?%G!<%?$N0lIt$K$N$_%"%/%;%9$9$k$?$a!$ItJ,E*$K=q$+$l$?%G!<%?$r8+$k$3(B
-$B$H$O$G$-$J$$!%(B
-
-%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.
-
-$B$$$/$D$+$N@)8f%U%C%/!J(B\hook{pretxncommit}$B$H(B\hook{pretxnchangegroup}$B!K$O%H(B
-$B%i%s%6%/%7%g%s$,$[$\40N;$7$?;~$K<B9T$5$l$k!%$9$Y$F$N%a%?%G!<%?$,=q$-9~$^(B
-$B$l$k$,!$$3$N;~E@$G$b(BMercurial$B$O%H%i%s%6%/%7%g%s$r85$KLa$9$3$H$,$G$-!$$=$N(B
-$B>l9g$O?7$7$/=q$+$l$?%G!<%?$O>C<:$9$k!%(B
-
-%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.
-
-$B$3$l$i$N%U%C%/$N$&$A(B1$B$D$,D9;~4V$K$o$?$C$F<B9T$5$l$F$$$k$H!$%j!<%@$,%A%'%s(B
-$B%8%;%C%H$N%a%?%G!<%?$rFI$`$3$H$N$G$-$k%?%$%`%&%#%s%I%&$,3+$/!%$3$N%A%'%s(B
-$B%8%;%C%H$O$^$@1JB3E*$J$b$N$K$J$C$F$*$i$:!$=>$C$F<B:_$9$k$H9M$($k$Y$-$G$O(B
-$B$J$$$b$N$G$"$k!%%U%C%/$,<B9T$5$l$F$$$k;~4V$,D9$/$J$l$P$J$k$[$I!$%?%$%`%&%#(B
-$B%s%I%&$,3+$/;~4V$bD9$/$J$k!%(B
-
-%\subsection{The problem illustrated}
-\subsection{$BLdBj$N>\:Y(B}
-
-%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.
-
-$B<BMQ$K$*$1$k(B\hook{pretxnchangegroup}$B%U%C%/$NNI$$;HMQK!$H$7$F$O!$E~Ce$7$?(B
-$BJQ99$,Cf1{$N%j%]%8%H%j$K<h$j9~$^$l$kA0$K<+F0$G%S%k%I$H%F%9%H$r9T$&$3$H$,(B
-$B9M$($i$l$k!%$3$l$K$h$j!$%S%k%I$rK8$2$kJQ99$OC/$b%j%]%8%H%j$K(Bpush$B$G$-$J$$(B
-$B$3$H$,3N<B$K$J$k!%%/%i%$%"%s%H$,%F%9%HCf$KJQ99$r(Bpull$B$9$k$3$H$,$G$-$l$P!$(B
-$B$3$N%F%9%H$NM-MQ@-$O%<%m$K$J$C$F$7$^$&!%5?$$$r;}$?$:$KC/$+$,%F%9%H$5$l$F(B
-$B$$$J$$JQ99$r(Bpull$B$G$-$k$N$G$"$l$P!$H`$i$N%S%k%I$O<:GT$9$k2DG=@-$,$"$k!%(B
-
-%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.
-
-$B$3$NLdBj$X$N5;=QE*$K:G$b0BA4$J2sEz$O!$(B``$BLgHV(B''$B%j%]%8%H%j$r(B\emph{$B0lJ}8~(B}$B$K(B
-$B@_Dj$9$k$3$H$G$"$k!%%j%]%8%H%j$r30It$+$i(Bpush$B$5$l$?JQ99$r<u$1<h$k$,!$C/$b(B
-pull$B$G$-$J$$$h$&$K@_Dj$9$k!J(B\hook{preoutgoing}$B%U%C%/$r;H$C$F%j%]%8%H%j$r(B
-$B%m%C%/$9$k!K!%(B\hook{changegroup}$B%U%C%/$r@_Dj$7!$%S%k%I$d%F%9%H$,@.8y$7$?(B
-$B$H$-$K8B$C$F!$%U%C%/$,?7$?$JJQ99$r%f!<%6$N(Bpull\emph{$B$G$-$k(B}$BJL$N%j%]%8%H(B
-$B%j$K(Bpush$B$9$k$h$&$K$9$k!%(B
-
-%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.
-
-$B<B:]>e$O!$$3$N$h$&$K=8Cf$7$?%\%H%k%M%C%/$rCV$/$3$H$ONI$$9M$($H$O8@$($:!$(B
-$B%H%i%s%6%/%7%g%s$N2D;k@-$OA4$/$J$$!%%W%m%8%'%/%H$N%5%$%:$*$h$S%S%k%I$H%F(B
-$B%9%H$KMW$9$k;~4V$,A}2C$9$k$K=>$C$F!$$3$N$h$&$J(B``$B;vA0$K;n$9(B''$B<jK!$OJI$KFM(B
-$B$-Ev$?$k!%%F%9%H$K;H$($k;~4V$G;+$-@Z$l$J$$$[$I$N%A%'%s%8%;%C%H$r;n$5$J$1(B
-$B$l$P$J$i$J$/$J$k$+$i$G$"$k!%%U%i%9%H%l!<%7%g%s$,Cy$k$N$OHr$1$i$l$J$$$@$m(B
-$B$&!%(B
-
-%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.
-
-$B$h$j%9%1!<%k$9$k<jK!$O!$3+H/<T$K(Bpush$BA0$N%S%k%I$H%F%9%H$r$5$;$k$3$H$G$"(B
-$B$k!%Cf1{$G<+F0$K$h$k%S%k%I$H%F%9%H$r9T$&$N$O!$(Bpush\emph{$B8e(B}$B$K!$A4$F$KLdBj(B
-$B$,$J$$$3$H$r3NG'$9$k$?$a$K9T$&!%$3$N%"%W%m!<%A$NMxE@$O%j%]%8%H%j$,JQ99$r(B
-$B<u$1F~$l$k%Z!<%9$K2?$b@)8B$r2]$5$J$$$3$H$G$"$k!%(B
-
 %\section{A short tutorial on using hooks}
 \section{$B%U%C%/$N;HMQK!(B}
 \label{sec:hook:simple}
--- 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$BG/$NCf:"(BChris Mason$B$O!$(Bquilt$B$N5!G=$r<h$jF~$l$F!$(BMercurial$B$K(Bquilt$B$N$h(B
-$B$&$JF0:n$rDI2C$9$k(BMercurial Queues$B$H$$$&%(%/%9%F%s%7%g%s$r=q$$$?!%(B
+2005$BG/$NCf:"!$(BChris Mason$B$O!$(Bquilt$B$N5!G=$r<h$jF~$l$F!$(BMercurial$B$K(Bquilt$B$N(B
+$B$h$&$JF0:n$rDI2C$9$k(BMercurial Queues$B$H$$$&%(%/%9%F%s%7%g%s$r=q$$$?!%(B

 %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 @@
 $B$$!%BgDq$N>l9g!$(B\sfilename{.rej}$B%U%!%$%k$r8+$F%?!<%2%C%H%U%!%$%k$rJT=8(B
 $B$7!$%j%8%'%/%H$5$l$?(Bhunk$B$r<j$GE,MQ$9$k$3$H$K$J$k!%(B

-%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.
-
-$BKA81$,9%$-$J$i!$(BLinux kerner$B%O%C%+!<$N(BNeil Brown$B$,=q$$$?(B
-\command{wiggle}~\cite{web:wiggle}$B$r;n$7$F$_$k$HNI$$!%$3$N%3%^%s%I$O(B
-\command{patch}$B$h$j$b@:NOE*$K%Q%C%A$NE,MQ$r;n$_$k!%(B
+%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:
-
-$BJL$N(BLinux kerner$B%O%C%+!<(B Chris Mason$B!J(BMercurial Queues$B$N:n<T$G$b$"$k!%!K(B
+Linux kerner$B%O%C%+!<(B Chris Mason$B!J(BMercurial Queues$B$N:n<T$G$b$"$k!%!K(B
 $B$O(B\command{mpatch}~\cite{web:mpatch}$B$H$$$&%D!<%k$r=q$$$?!%$3$N%3%^%s%I$O(B
 \command{patch}$B%3%^%s%I$G%j%8%'%/%H$5$l$?(Bhunk$B$NE,MQ$r<+F02=$9(B
 $B$k!%(B\command{mpatch}$B%3%^%s%I$O!$(Bhunk$B$,%j%8%'%/%H$5$l$k<g$J860x(B4$B$D$KBP1~(B
@@ -1067,17 +1058,79 @@
       $B$9$k(B
 \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}$B$^$?$O(B\command{mpatch}$B$r;HMQ$7$?>l9g$O!$7k2L$K:Y?4$NCm0U(B
-$B$,I,MW$G$"$k!%<B:]$K$O(B\command{mpatch}$B$O%D!<%k$N=PNO$GFs=E%A%'%C%/$r6/@)(B
-$B$7!$F0:n$,=*$k$H<+F0E*$K%^!<%8%W%m%0%i%`$r5/F0$9$k!%$3$l$K$h$C$F:n6H$r3N(B
-$BG'$7!$%^!<%8$r40N;$9$k$3$H$,$G$-$k!%(B
+\command{mpatch}$B$r;HMQ$7$?>l9g$O!$7k2L$K:Y?4$NCm0U$,I,MW$G$"$k!%<B:]$K$O(B
+\command{mpatch}$B$O%D!<%k$N=PNO$GFs=E%A%'%C%/$r6/@)$7!$F0:n$,=*$k$H<+F0E*(B
+$B$K%^!<%8%W%m%0%i%`$r5/F0$9$k!%$3$l$K$h$C$F:n6H$r3NG'$7!$I,MW$J%^!<%8$r40(B
+$BN;$9$k$3$H$,$G$-$k!%(B
+
+
+%\section{More on patch management}
+\section{$B$5$i$J$k%Q%C%A4IM}(B}
+
+%As you grow familiar with MQ, you will find yourself wanting
+%to perform other kinds of patch management operations.
+
+MQ$B$K47$l$k$K=>$C$F!$JL$NJ}K!$G$b%Q%C%A4IM}$r$7$?$/$J$k$@$m$&!%(B
+
+%\subsection{Deleting unwanted patches}
+\subsection{$BITMW$J%Q%C%A$r>C5n$9$k(B}
+
+%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.
+
+$B%Q%C%A$r>C5n$9$k$K$O!$(B\command{qdelete}$B%3%^%s%I$rMQ$$$F!$%Q%C%A%U%!%$%k$N(B
+$B>C5n$H%Q%C%A%(%s%H%j$N%Q%C%A%7%j!<%:$+$i$NKu>C$r9T$&!%(B\command{qdelete}$B$O(B
+$BE,MQCf$N%Q%C%A$O>C5n$7$J$$!%(B
+
+% &interaction.ch11-qdelete.go;
+\interaction{ch11-qdelete.go}
+
+%\subsection{Converting to and from permanent revisions}
+\subsection{$B1JB3E*$J%j%S%8%g%s$H$NAj8_JQ49(B}
+
+%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.
+
+$B%Q%C%A$G$N:n6H$,=*$j!$$3$l$r1JB3E*$J%A%'%s%8%;%C%H$XJQ49$7$?$$>l9g$O!$(B
+\hgxopt{mq}{qdelete}{-r}$B%3%^%s%I$rMQ$$$k!%(B\option{-r}$B%*%W%7%g%s$K%j%S%8%g(B
+$B%s$rEO$7!$$I$N%Q%C%A$rDL>o$N%A%'%s%8%;%C%H$KJQ49$7$?$$$N$+;XDj$9$k!%JQ49(B
+$BBP>]$N%Q%C%A$O$9$G$KE,MQ$5$l$F$$$J$1$l$P$J$i$J$$!%(B
+
+%&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}$B%3%^%s%I$K(B\option{-r}$B%*%W%7%g%s$rEO$7$F!$$9$G$KB8:_$9$k(B
+$B%A%'%s%8%;%C%H$r%Q%C%A$KJQ49$9$k$3$H$b$G$-$k!%(B
+
+%&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.
+
+$B%A%'%s%8%;%C%H$+$i%Q%C%A$X$NJQ49$,0UL#$r;}$D$N$O!$%A%'%s%8%;%C%H$r$^$@B>(B
+$B$N%j%]%8%H%j$KGH5Z$5$;$F$$$J$$>l9g$K8B$i$l$k!%(BMercurial$B$O%Q%C%A$KJQ49$7$?(B
+$B%A%'%s%8%;%C%H$r85$N%A%'%s%8%;%C%H$H$OL54X78$J$b$N$H$7$F07$&$?$a!$%Q%C%A(B
+$B$r%j%U%l%C%7%e$9$kEY$K%A%'%s%8%;%C%H(BID$B$OJQ$o$k!%$9$G$KJL$N%j%]%8%H%j$K%A%'(B
+$B%s%8%;%C%H$r%W%C%7%e$7$F$$$k$J$i$P!$$3$l$i$N(BID$B$OAj0c$7$F$7$^$&!%(B
+

 %\section{Getting the best performance out of MQ}
 \section{MQ$B$r:GBg8B$K3hMQ$9$k(B}
@@ -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