Mercurial > hgbook

changeset 691:4ce9d0754af3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Remove the words "section", "chapter", etc from in front of xref tags.
author Bryan O'Sullivan <bos@serpentine.com>
date Thu, 26 Mar 2009 21:22:03 -0700
parents b788b405e141
children 8dfdbe1cf982
files en/appA-cmdref.xml en/appD-license.xml en/ch00-preface.xml en/ch01-tour-basic.xml en/ch02-tour-merge.xml en/ch03-concepts.xml en/ch04-daily.xml en/ch05-collab.xml en/ch08-undo.xml en/ch09-hook.xml en/ch10-template.xml en/ch11-mq.xml en/ch12-mq-collab.xml en/ch13-hgext.xml
diffstat 14 files changed, 288 insertions(+), 288 deletions(-) [+]
line wrap: on
line diff
--- a/en/appA-cmdref.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/appA-cmdref.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -12,7 +12,7 @@
 
 <para id="x_655">Show differences between revisions for the specified files or
 directories, using the unified diff format.  For a description of the
-unified diff format, see section <xref linkend="sec:mq:patch"/>.</para>
+unified diff format, see <xref linkend="sec:mq:patch"/>.</para>
 
 <para id="x_656">By default, this command does not print diffs for files that Mercurial
 considers to contain binary data.  To control this behaviour, see the
--- a/en/appD-license.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/appD-license.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -32,7 +32,7 @@
 
     <para id="x_63c">The reference must be immediately followed with any options
       elected by the author(s) and/or publisher of the document (see
-      section <xref linkend="sec:opl:options"/>).</para>
+      <xref linkend="sec:opl:options"/>).</para>
 
     <para id="x_63d">Commercial redistribution of Open Publication-licensed
       material is permitted.</para>
--- a/en/ch00-preface.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch00-preface.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -61,7 +61,7 @@
 	    can revert to an earlier version of one or more files.  In
 	    fact, a <emphasis>really</emphasis> good revision control
 	    tool will even help you to efficiently figure out exactly
-	    when a problem was introduced (see section <xref
+	    when a problem was introduced (see <xref
 	      linkend="sec:undo:bisect"/> for details).</para></listitem>
 	<listitem><para id="x_75">It will help you to work simultaneously on,
 	    and manage the drift between, multiple versions of your
@@ -167,7 +167,7 @@
     <para id="x_87">As an instance of this, several consecutive commits in an
       example can show up as having occurred during the same second.
       You can see this occur in the <literal
-	role="hg-ext">bisect</literal> example in section <xref
+	role="hg-ext">bisect</literal> example in <xref
 	linkend="sec:undo:bisect"/>, for instance.</para>
 
     <para id="x_88">So when you're reading examples, don't place too much weight
--- a/en/ch01-tour-basic.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch01-tour-basic.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -246,8 +246,8 @@
 	log</command> is purely a summary; it is missing a lot of
       detail.</para>
 
-    <para id="x_23">Figure <xref linkend="fig:tour-basic:history"/> provides a
-      graphical representation of the history of the <filename
+    <para id="x_23"><xref linkend="fig:tour-basic:history"/> provides
+      a graphical representation of the history of the <filename
 	class="directory">hello</filename> repository, to make it a
       little easier to see which direction history is
       <quote>flowing</quote> in.  We'll be returning to this figure
@@ -351,13 +351,13 @@
 
       &interaction.tour.log-v;
 
-      <para id="x_2f">If you want to see both the description and content of a
-	change, add the <option role="hg-opt-log">-p</option> (or
-	<option role="hg-opt-log">--patch</option>) option.  This
-	displays the content of a change as a <emphasis>unified
-	  diff</emphasis> (if you've never seen a unified diff before,
-	see section <xref linkend="sec:mq:patch"/> for an
-	overview).</para>
+      <para id="x_2f">If you want to see both the description and
+	content of a change, add the <option
+	  role="hg-opt-log">-p</option> (or <option
+	  role="hg-opt-log">--patch</option>) option.  This displays
+	the content of a change as a <emphasis>unified diff</emphasis>
+	(if you've never seen a unified diff before, see <xref
+	  linkend="sec:mq:patch"/> for an overview).</para>
 
       &interaction.tour.log-vp;
 
@@ -509,11 +509,12 @@
 	<listitem><para id="x_44">If you have set the <envar>HGUSER</envar>
 	    environment variable, this is checked
 	    next.</para></listitem>
-	<listitem><para id="x_45">If you create a file in your home directory
-	    called <filename role="special">.hgrc</filename>, with a
-	    <envar role="rc-item-ui">username</envar> entry, that will
-	    be used next.  To see what the contents of this file
-	    should look like, refer to section <xref
+	<listitem><para id="x_45">If you create a file in your home
+	    directory called <filename
+	      role="special">.hgrc</filename>, with a <envar
+	      role="rc-item-ui">username</envar> entry, that will be
+	    used next.  To see what the contents of this file should
+	    look like, refer to <xref
 	      linkend="sec:tour-basic:username"/>
 	    below.</para></listitem>
 	<listitem><para id="x_46">If you have set the <envar>EMAIL</envar>
@@ -727,12 +728,12 @@
     <sect2>
       <title>Updating the working directory</title>
 
-      <para id="x_5e">We have so far glossed over the relationship between a
-	repository and its working directory.  The <command
+      <para id="x_5e">We have so far glossed over the relationship
+	between a repository and its working directory.  The <command
 	  role="hg-cmd">hg pull</command> command that we ran in
-	section <xref linkend="sec:tour:pull"/> brought changes
-	into the repository, but if we check, there's no sign of those
-	changes in the working directory.  This is because <command
+	<xref linkend="sec:tour:pull"/> brought changes into the
+	repository, but if we check, there's no sign of those changes
+	in the working directory.  This is because <command
 	  role="hg-cmd">hg pull</command> does not (by default) touch
 	the working directory.  Instead, we use the <command
 	  role="hg-cmd">hg update</command> command to do this.</para>
@@ -756,7 +757,7 @@
 	  role="hg-cmd">hg pull</command>.</para>
 
       <para id="x_61">If you look back at the output of <command
-	  role="hg-cmd">hg pull</command> in section <xref
+	  role="hg-cmd">hg pull</command> in <xref
 	    linkend="sec:tour:pull"/> when we ran it without <option
 	  role="hg-opt-pull">-u</option>, you can see that it printed
 	a helpful reminder that we'd have to take an explicit step to
@@ -770,7 +771,7 @@
 
       &interaction.tour.parents;
 
-      <para id="x_63">If you look back at figure <xref
+      <para id="x_63">If you look back at <xref
 	  linkend="fig:tour-basic:history"/>,
 	you'll see arrows connecting each changeset.  The node that
 	the arrow leads <emphasis>from</emphasis> in each case is a
--- a/en/ch02-tour-merge.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch02-tour-merge.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -37,7 +37,7 @@
     <para id="x_33d">We should now have two copies of
       <filename>hello.c</filename> with different contents.  The
       histories of the two repositories have also diverged, as
-      illustrated in figure <xref
+      illustrated in <xref
 	linkend="fig:tour-merge:sep-repos"/>.</para>
 
     &interaction.tour.merge.cat;
@@ -83,13 +83,13 @@
 	</mediaobject>
       </figure>
 
-      <para id="x_343">In figure <xref linkend="fig:tour-merge:pull"/>, you can
+      <para id="x_343">In <xref linkend="fig:tour-merge:pull"/>, you can
 	see the effect of the pull from <filename
 	  class="directory">my-hello</filename> into <filename
 	  class="directory">my-new-hello</filename>.  The history that
 	was already present in <filename
 	  class="directory">my-new-hello</filename> is untouched, but
-	a new revision has been added.  By referring to figure <xref
+	a new revision has been added.  By referring to <xref
 	  linkend="fig:tour-merge:sep-repos"/>, we can see that the
 	<emphasis>changeset ID</emphasis> remains the same in the new
 	repository, but the <emphasis>revision number</emphasis> has
@@ -156,7 +156,7 @@
 
       &interaction.tour.merge.tip;
 
-      <para id="x_34a">In figure <xref
+      <para id="x_34a">In <xref
 	  linkend="fig:tour-merge:merge"/>, you can see a
 	representation of what happens to the working directory during
 	the merge, and how this affects the repository when the commit
@@ -184,7 +184,7 @@
       </mediaobject>
     </figure>
 
-    <para id="x_34d">Figure <xref linkend="fig:tour-merge:conflict"/> illustrates
+    <para id="x_34d"><xref linkend="fig:tour-merge:conflict"/> illustrates
       an instance of two conflicting changes to a document.  We
       started with a single version of the file; then we made some
       changes; while someone else made different changes to the same
@@ -214,7 +214,7 @@
 	<command>kdiff3</command>, which I'll use to describe the
 	features that are common to graphical file merging tools.  You
 	can see a screenshot of <command>kdiff3</command> in action in
-	figure <xref linkend="fig:tour-merge:kdiff3"/>.  The kind of
+	<xref linkend="fig:tour-merge:kdiff3"/>.  The kind of
 	merge it is performing is called a <emphasis>three-way
 	  merge</emphasis>, because there are three different versions
 	of the file of interest to us.  The tool thus splits the upper
@@ -274,7 +274,7 @@
       <title>A worked example</title>
 
       <para id="x_359">In this example, we will reproduce the file modification
-	history of figure <xref linkend="fig:tour-merge:conflict"/>
+	history of <xref linkend="fig:tour-merge:conflict"/>
 	above.  Let's begin by creating a repository with a base
 	version of our document.</para>
 
--- a/en/ch03-concepts.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch03-concepts.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -46,7 +46,7 @@
 	are combined in a single <quote><literal>.i</literal></quote>
 	file.  The correspondence between a file in the working
 	directory and the filelog that tracks its history in the
-	repository is illustrated in figure <xref
+	repository is illustrated in <xref
 	  linkend="fig:concepts:filelog"/>.</para>
 
       <figure id="fig:concepts:filelog">
@@ -96,7 +96,7 @@
 	changelog contains a pointer to a single revision of the
 	manifest.  A revision of the manifest stores a pointer to a
 	single revision of each filelog tracked when that changeset
-	was created.  These relationships are illustrated in figure
+	was created.  These relationships are illustrated in
 	<xref linkend="fig:concepts:metadata"/>.</para>
 
       <figure id="fig:concepts:metadata">
@@ -201,7 +201,7 @@
 	quickly.  This approach works so well that it has since been
 	copied by several other revision control systems.</para>
 
-      <para id="x_2fd">Figure <xref linkend="fig:concepts:snapshot"/> illustrates
+      <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustrates
 	the idea.  In an entry in a revlog's index file, Mercurial
 	stores the range of entries from the data file that it must
 	read to reconstruct a particular revision.</para>
@@ -273,7 +273,7 @@
       <quote>there is no parent here</quote>.  This hash is simply a
       string of zeroes.</para>
 
-    <para id="x_305">In figure <xref linkend="fig:concepts:revlog"/>, you can see
+    <para id="x_305">In <xref linkend="fig:concepts:revlog"/>, you can see
       an example of the conceptual structure of a revlog.  Filelogs,
       manifests, and changelogs all have this same structure; they
       differ only in the kind of data stored in each delta or
@@ -347,7 +347,7 @@
 	</mediaobject>
       </figure>
 
-      <para id="x_30d">Figure <xref linkend="fig:concepts:wdir"/> shows the
+      <para id="x_30d"><xref linkend="fig:concepts:wdir"/> shows the
 	normal state of the working directory, where it has a single
 	changeset as parent.  That changeset is the
 	<emphasis>tip</emphasis>, the newest changeset in the
@@ -370,11 +370,11 @@
 	the new changeset will have the parents of the working
 	directory as its parents.</para>
 
-      <para id="x_310">After a commit, Mercurial will update the parents of the
-	working directory, so that the first parent is the ID of the
-	new changeset, and the second is the null ID.  This is shown
-	in figure <xref linkend="fig:concepts:wdir-after-commit"/>.
-	Mercurial
+      <para id="x_310">After a commit, Mercurial will update the
+	parents of the working directory, so that the first parent is
+	the ID of the new changeset, and the second is the null ID.
+	This is shown in <xref
+	  linkend="fig:concepts:wdir-after-commit"/>. Mercurial
 	doesn't touch any of the files in the working directory when
 	you commit; it just modifies the dirstate to note its new
 	parents.</para>
@@ -392,7 +392,7 @@
 	interested in, and then examine the files in the working
 	directory directly to see their contents as they were when you
 	committed that changeset.  The effect of this is shown in
-	figure <xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
+	<xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
 
       <figure id="fig:concepts:wdir-pre-branch">
 	<title>The working directory, updated to an older
@@ -403,15 +403,15 @@
 	</mediaobject>
       </figure>
 
-      <para id="x_313">Having updated the working directory to an older
-	changeset, what happens if you make some changes, and then
-	commit?  Mercurial behaves in the same way as I outlined
+      <para id="x_313">Having updated the working directory to an
+	older changeset, what happens if you make some changes, and
+	then commit?  Mercurial behaves in the same way as I outlined
 	above.  The parents of the working directory become the
 	parents of the new changeset.  This new changeset has no
 	children, so it becomes the new tip.  And the repository now
 	contains two changesets that have no children; we call these
 	<emphasis>heads</emphasis>.  You can see the structure that
-	this creates in figure <xref
+	this creates in <xref
 	  linkend="fig:concepts:wdir-branch"/>.</para>
 
       <figure id="fig:concepts:wdir-branch">
@@ -450,10 +450,10 @@
     <sect2>
       <title>Merging heads</title>
 
-      <para id="x_317">When you run the <command role="hg-cmd">hg merge</command>
-	command, Mercurial leaves the first parent of the working
-	directory unchanged, and sets the second parent to the
-	changeset you're merging with, as shown in figure <xref
+      <para id="x_317">When you run the <command role="hg-cmd">hg
+	  merge</command> command, Mercurial leaves the first parent
+	of the working directory unchanged, and sets the second parent
+	to the changeset you're merging with, as shown in <xref
 	  linkend="fig:concepts:wdir-merge"/>.</para>
 
       <figure id="fig:concepts:wdir-merge">
@@ -588,13 +588,13 @@
     <sect2>
       <title>Read/write ordering and atomicity</title>
 
-      <para id="x_32a">Appending to files isn't the whole story when it comes to
-	guaranteeing that a reader won't see a partial write.  If you
-	recall figure <xref linkend="fig:concepts:metadata"/>,
-	revisions in the
-	changelog point to revisions in the manifest, and revisions in
-	the manifest point to revisions in filelogs.  This hierarchy
-	is deliberate.</para>
+      <para id="x_32a">Appending to files isn't the whole story when
+	it comes to guaranteeing that a reader won't see a partial
+	write.  If you recall <xref linkend="fig:concepts:metadata"/>,
+	revisions in
+	the changelog point to revisions in the manifest, and
+	revisions in the manifest point to revisions in filelogs.
+	This hierarchy is deliberate.</para>
 
       <para id="x_32b">A writer starts a transaction by writing filelog and
 	manifest data, and doesn't write any changelog data until
--- a/en/ch04-daily.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch04-daily.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -328,7 +328,7 @@
 	Unix-like systems, that's <command>cp</command>) to make a
 	copy of a file, then <command role="hg-cmd">hg add</command>
 	the new copy by hand.  Before you do so, though, please do
-	reread section <xref linkend="sec:daily:why-copy"/>, and make
+	reread <xref linkend="sec:daily:why-copy"/>, and make
 	an informed
 	decision that this behaviour is not appropriate to your
 	specific case.</para>
@@ -529,9 +529,9 @@
       decide it was a mistake, you can still do something about it,
       though your options may be more limited.</para>
 
-    <para id="x_1e5">For more information about the <command role="hg-cmd">hg
-	revert</command> command, and details about how to deal with
-      changes you have already committed, see chapter <xref
+    <para id="x_1e5">For more information about the <command
+	role="hg-cmd">hg revert</command> command, and details about
+      how to deal with changes you have already committed, see <xref
 	linkend="chap:undo"/>.</para>
 
   </sect1>
--- a/en/ch05-collab.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch05-collab.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -42,16 +42,16 @@
       the master Mercurial repository at <ulink
 	url="http://www.selenic.com/repo/hg?style=gitweb">http://www.selenic.com/repo/hg?style=gitweb</ulink>.</para>
 
-    <para id="x_450">If you're interested in providing a web interface to your
-      own repositories, Mercurial provides two ways to do this.  The
-      first is using the <command role="hg-cmd">hg serve</command>
-      command, which is best suited to short-term
-      <quote>lightweight</quote> serving.  See section <xref
+    <para id="x_450">If you're interested in providing a web interface
+      to your own repositories, Mercurial provides two ways to do
+      this.  The first is using the <command role="hg-cmd">hg
+	serve</command> command, which is best suited to short-term
+      <quote>lightweight</quote> serving.  See <xref
 	linkend="sec:collab:serve"/> below for details of how to use
       this command.  If you have a long-lived repository that you'd
       like to make permanently available, Mercurial has built-in
       support for the CGI (Common Gateway Interface) standard, which
-      all common web servers support.  See section <xref
+      all common web servers support.  See <xref
 	linkend="sec:collab:cgi"/> for details of CGI
       configuration.</para>
 
@@ -115,19 +115,19 @@
 	place) and spend several days more or less locked in there,
 	hacking intensely on a handful of projects.</para>
 
-      <para id="x_457">A sprint is the perfect place to use the <command
-	  role="hg-cmd">hg serve</command> command, since <command
-	  role="hg-cmd">hg serve</command> does not require any fancy
-	server infrastructure.  You can get started with <command
-	  role="hg-cmd">hg serve</command> in moments, by reading
-	section <xref linkend="sec:collab:serve"/> below.  Then simply
-	tell
-	the person next to you that you're running a server, send the
-	URL to them in an instant message, and you immediately have a
-	quick-turnaround way to work together.  They can type your URL
-	into their web browser and quickly review your changes; or
-	they can pull a bugfix from you and verify it; or they can
-	clone a branch containing a new feature and try it out.</para>
+      <para id="x_457">A sprint is the perfect place to use the
+	<command role="hg-cmd">hg serve</command> command, since
+	<command role="hg-cmd">hg serve</command> does not require any
+	fancy server infrastructure.  You can get started with
+	<command role="hg-cmd">hg serve</command> in moments, by
+	reading <xref linkend="sec:collab:serve"/> below.  Then simply
+	tell the person next to you that you're running a server, send
+	the URL to them in an instant message, and you immediately
+	have a quick-turnaround way to work together.  They can type
+	your URL into their web browser and quickly review your
+	changes; or they can pull a bugfix from you and verify it; or
+	they can clone a branch containing a new feature and try it
+	out.</para>
 
       <para id="x_458">The charm, and the problem, with doing things in an ad hoc
 	fashion like this is that only people who know about your
@@ -162,16 +162,15 @@
 	lets us put off publishing the potentially unsafe change until
 	it has had a little testing.</para>
 
-      <para id="x_45c">In this kind of scenario, people usually use the
-	<command>ssh</command> protocol to securely push changes to
-	the central repository, as documented in section <xref
-	  linkend="sec:collab:ssh"/>.  It's also
-	usual to publish a read-only copy of the repository over HTTP
-	using CGI, as in section <xref linkend="sec:collab:cgi"/>.
-	Publishing over HTTP
-	satisfies the needs of people who don't have push access, and
-	those who want to use web browsers to browse the repository's
-	history.</para>
+      <para id="x_45c">In this kind of scenario, people usually use
+	the <command>ssh</command> protocol to securely push changes
+	to the central repository, as documented in <xref
+	  linkend="sec:collab:ssh"/>.  It's also usual to publish a
+	read-only copy of the repository over HTTP using CGI, as in
+	<xref linkend="sec:collab:cgi"/>. Publishing
+	over HTTP satisfies the needs of people who don't have push
+	access, and those who want to use web browsers to browse the
+	repository's history.</para>
 
     </sect2>
     <sect2>
@@ -402,14 +401,14 @@
     <sect2>
       <title>Where collaboration meets branch management</title>
 
-      <para id="x_479">Once you and your team set up some shared repositories and
-	start propagating changes back and forth between local and
-	shared repos, you begin to face a related, but slightly
-	different challenge: that of managing the multiple directions
-	in which your team may be moving at once.  Even though this
-	subject is intimately related to how your team collaborates,
-	it's dense enough to merit treatment of its own, in chapter
-	<xref linkend="chap:branch"/>.</para>
+      <para id="x_479">Once you and your team set up some shared
+	repositories and start propagating changes back and forth
+	between local and shared repos, you begin to face a related,
+	but slightly different challenge: that of managing the
+	multiple directions in which your team may be moving at once.
+	Even though this subject is intimately related to how your
+	team collaborates, it's dense enough to merit treatment of its
+	own, in <xref linkend="chap:branch"/>.</para>
 
     </sect2>
   </sect1>
@@ -1110,15 +1109,17 @@
       <para id="x_4d6">You'll need to copy this script into your <filename
 	  class="directory">public_html</filename> directory, and
 	ensure that it's executable.</para>
+
       <programlisting>cp .../hgwebdir.cgi ~/public_html
 chmod 755 ~/public_html ~/public_html/hgwebdir.cgi</programlisting>
-      <para id="x_4d7">With basic configuration out of the way, try to visit
-	<ulink url="http://myhostname/
+
+      <para id="x_4d7">With basic configuration out of the way, try to
+	visit <ulink url="http://myhostname/
 	  myuser/hgwebdir.cgi">http://myhostname/
 	  myuser/hgwebdir.cgi</ulink> in your browser.  It should
 	display an empty list of repositories.  If you get a blank
 	window or error message, try walking through the list of
-	potential problems in section <xref
+	potential problems in <xref
 	  linkend="sec:collab:wtf"/>.</para>
 
       <para id="x_4d8">The <filename role="special">hgwebdir.cgi</filename>
@@ -1313,15 +1314,16 @@
 	    rows when you are looking at a table, this number controls
 	    the number of rows in each stripe.</para>
 	</listitem>
-	<listitem><para id="x_4f0"><envar role="rc-item-web">style</envar>:
-	    Controls the template Mercurial uses to display the web
-	    interface.  Mercurial ships with two web templates, named
+	<listitem><para id="x_4f0"><envar
+	      role="rc-item-web">style</envar>: Controls the template
+	    Mercurial uses to display the web interface.  Mercurial
+	    ships with two web templates, named
 	    <literal>default</literal> and <literal>gitweb</literal>
 	    (the latter is much more visually attractive).  You can
-	    also specify a custom template of your own; see chapter
-	    <xref linkend="chap:template"/> for details.
-	    Here, you can see how to enable the
-	    <literal>gitweb</literal> style.</para>
+	    also specify a custom template of your own; see 
+	    <xref linkend="chap:template"/> for details. Here, you can
+	    see how to enable the <literal>gitweb</literal>
+	    style.</para>
 	  <programlisting>[web]
 style = gitweb</programlisting>
 	</listitem>
--- a/en/ch08-undo.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch08-undo.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -30,15 +30,15 @@
     <sect2 id="sec:undo:rollback">
       <title>Rolling back a transaction</title>
 
-      <para id="x_d4">In section <xref linkend="sec:concepts:txn"/>, I mentioned
-	that Mercurial treats each modification of a repository as a
-	<emphasis>transaction</emphasis>.  Every time you commit a
-	changeset or pull changes from another repository, Mercurial
-	remembers what you did.  You can undo, or <emphasis>roll
-	  back</emphasis>, exactly one of these actions using the
-	<command role="hg-cmd">hg rollback</command> command.  (See
-	section <xref linkend="sec:undo:rollback-after-push"/> for an
-	important caveat about the use of this command.)</para>
+      <para id="x_d4">In <xref linkend="sec:concepts:txn"/>, I
+	mentioned that Mercurial treats each modification of a
+	repository as a <emphasis>transaction</emphasis>.  Every time
+	you commit a changeset or pull changes from another
+	repository, Mercurial remembers what you did.  You can undo,
+	or <emphasis>roll back</emphasis>, exactly one of these
+	actions using the <command role="hg-cmd">hg rollback</command>
+	command.  (See <xref linkend="sec:undo:rollback-after-push"/>
+	for an important caveat about the use of this command.)</para>
 
       <para id="x_d5">Here's a mistake that I often find myself making:
 	committing a change in which I've created a new file, but
@@ -300,12 +300,12 @@
       an entire changeset automatically, and building blocks that let
       you reverse part of a changeset by hand.</para>
 
-    <para id="x_f6">Before you read this section, here's something to keep in
-      mind: the <command role="hg-cmd">hg backout</command> command
-      undoes changes by <emphasis>adding</emphasis> history, not by
-      modifying or erasing it.  It's the right tool to use if you're
-      fixing bugs, but not if you're trying to undo some change that
-      has catastrophic consequences.  To deal with those, see section
+    <para id="x_f6">Before you read this section, here's something to
+      keep in mind: the <command role="hg-cmd">hg backout</command>
+      command undoes changes by <emphasis>adding</emphasis> history,
+      not by modifying or erasing it.  It's the right tool to use if
+      you're fixing bugs, but not if you're trying to undo some change
+      that has catastrophic consequences.  To deal with those, see
       <xref linkend="sec:undo:aaaiiieee"/>.</para>
 
     <sect2>
@@ -353,10 +353,9 @@
 	&interaction.backout.simple.log; Notice that the new changeset
 	that <command role="hg-cmd">hg backout</command> has created
 	is a child of the changeset we backed out.  It's easier to see
-	this in figure <xref
-	  linkend="fig:undo:backout"/>, which presents a graphical
-	view of the change history.  As you can see, the history is
-	nice and linear.</para>
+	this in <xref linkend="fig:undo:backout"/>, which presents a
+	graphical view of the change history.  As you can see, the
+	history is nice and linear.</para>
 
       <figure id="fig:undo:backout">
 	<title>Backing out a change using the <command
@@ -391,7 +390,7 @@
 
       &interaction.backout.non-tip.cat;
 
-      <para id="x_100">As the graphical history in figure <xref
+      <para id="x_100">As the graphical history in <xref
 	  linkend="fig:undo:backout-non-tip"/> illustrates, Mercurial
 	actually commits <emphasis>two</emphasis> changes in this kind
 	of situation (the box-shaped nodes are the ones that Mercurial
@@ -463,7 +462,7 @@
       &interaction.backout.manual.log;
 
       <para id="x_108">Again, it's easier to see what has happened by looking at
-	a graph of the revision history, in figure <xref
+	a graph of the revision history, in <xref
 	  linkend="fig:undo:backout-manual"/>.  This makes it clear
 	that when we use <command role="hg-cmd">hg backout</command>
 	to back out a change other than the tip, Mercurial adds a new
@@ -505,8 +504,8 @@
 
       &interaction.backout.manual.merge;
 
-      <para id="x_10e">Afterwards, the graphical history of our repository looks
-	like figure
+      <para id="x_10e">Afterwards, the graphical history of our
+	repository looks like
 	<xref linkend="fig:undo:backout-manual-merge"/>.</para>
 
       <figure id="fig:undo:backout-manual-merge">
@@ -614,14 +613,14 @@
       that you want to pull a brown paper bag over your head), let me
       first discuss some approaches that probably won't work.</para>
 
-    <para id="x_11e">Since Mercurial treats history as accumulative&emdash;every
-      change builds on top of all changes that preceded it&emdash;you
-      generally can't just make disastrous changes disappear.  The one
-      exception is when you've just committed a change, and it hasn't
-      been pushed or pulled into another repository.  That's when you
-      can safely use the <command role="hg-cmd">hg rollback</command>
-      command, as I detailed in section <xref
-	linkend="sec:undo:rollback"/>.</para>
+    <para id="x_11e">Since Mercurial treats history as
+      accumulative&emdash;every change builds on top of all changes
+      that preceded it&emdash;you generally can't just make disastrous
+      changes disappear.  The one exception is when you've just
+      committed a change, and it hasn't been pushed or pulled into
+      another repository.  That's when you can safely use the <command
+	role="hg-cmd">hg rollback</command> command, as I detailed in
+      <xref linkend="sec:undo:rollback"/>.</para>
 
     <para id="x_11f">After you've pushed a bad change to another repository, you
       <emphasis>could</emphasis> still use <command role="hg-cmd">hg
--- a/en/ch09-hook.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch09-hook.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -17,9 +17,9 @@
   <sect1>
     <title>An overview of hooks in Mercurial</title>
 
-    <para id="x_1e8">Here is a brief list of the hooks that Mercurial supports.
-      We will revisit each of these hooks in more detail later, in
-      section <xref linkend="sec:hook:ref"/>.</para>
+    <para id="x_1e8">Here is a brief list of the hooks that Mercurial
+      supports. We will revisit each of these hooks in more detail
+      later, in <xref linkend="sec:hook:ref"/>.</para>
 
     <itemizedlist>
       <listitem><para id="x_1e9"><literal role="hook">changegroup</literal>: This
@@ -393,12 +393,12 @@
 	before both.
       </para>
 
-      <para id="x_218">It is a good idea to use a somewhat descriptive extension
-	when you define a new hook.  This will help you to remember
-	what the hook was for.  If the hook fails, you'll get an error
-	message that contains the hook name and extension, so using a
-	descriptive extension could give you an immediate hint as to
-	why the hook failed (see section <xref
+      <para id="x_218">It is a good idea to use a somewhat descriptive
+	extension when you define a new hook.  This will help you to
+	remember what the hook was for.  If the hook fails, you'll get
+	an error message that contains the hook name and extension, so
+	using a descriptive extension could give you an immediate hint
+	as to why the hook failed (see <xref
 	  linkend="sec:hook:perm"/> for an example).
       </para>
 
@@ -1094,7 +1094,7 @@
 	  mapping committer names to user names.
 	</para>
 
-	<para id="x_263">Recall from section <xref
+	<para id="x_263">Recall from <xref
 	    linkend="sec:hook:bugzilla:config"/> above that the user
 	  that runs the Mercurial process on the server is also the
 	  one that will run the <filename>processmail</filename>
@@ -1250,10 +1250,9 @@
 	      sources of changesets to consider.  This lets you limit
 	      <literal role="hg-ext">notify</literal> to only sending
 	      out email about changes that remote users pushed into
-	      this repository via a server, for example.  See section
-	      <xref
-		linkend="sec:hook:sources"/> for the sources you can
-	      specify here.
+	      this repository via a server, for example.  See 
+	      <xref linkend="sec:hook:sources"/> for the sources you
+	      can specify here.
 	    </para>
 	  </listitem></itemizedlist>
 
@@ -1502,23 +1501,23 @@
 	      role="hg-cmd">hg unbundle</command>.
 	  </para>
 	</listitem>
-	<listitem><para id="x_294"><literal>source</literal>: A string.  The
-	    source of these changes.  See section <xref
+	<listitem><para id="x_294"><literal>source</literal>: A
+	    string.  The source of these changes.  See <xref
 	      linkend="sec:hook:sources"/> for details.
 	  </para>
 	</listitem>
-	<listitem><para id="x_295"><literal>url</literal>: A URL.  The location
-	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
-	    information.
+	<listitem><para id="x_295"><literal>url</literal>: A URL.  The
+	    location of the remote repository, if known.  See <xref
+	      linkend="sec:hook:url"/> for more information.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_296">See also: <literal role="hook">incoming</literal> (section
-	<xref linkend="sec:hook:incoming"/>), <literal
-	  role="hook">prechangegroup</literal> (section <xref
+      <para id="x_296">See also: <literal
+	  role="hook">incoming</literal> (<xref
+	  linkend="sec:hook:incoming"/>), <literal
+	  role="hook">prechangegroup</literal> (<xref
 	  linkend="sec:hook:prechangegroup"/>), <literal
-	  role="hook">pretxnchangegroup</literal> (section <xref
+	  role="hook">pretxnchangegroup</literal> (<xref
 	  linkend="sec:hook:pretxnchangegroup"/>)
       </para>
 
@@ -1548,9 +1547,10 @@
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_29c">See also: <literal role="hook">precommit</literal>
-	(section <xref linkend="sec:hook:precommit"/>), <literal
-	  role="hook">pretxncommit</literal> (section <xref
+      <para id="x_29c">See also: <literal
+	  role="hook">precommit</literal> (<xref
+	  linkend="sec:hook:precommit"/>), <literal
+	  role="hook">pretxncommit</literal> (<xref
 	  linkend="sec:hook:pretxncommit"/>)
       </para>
 
@@ -1566,10 +1566,10 @@
 	each added changeset.
       </para>
 
-      <para id="x_29e">You can use this hook for the same purposes as the
-	<literal role="hook">changegroup</literal> hook (section <xref
-	  linkend="sec:hook:changegroup"/>); it's simply
-	more convenient sometimes to run a hook once per group of
+      <para id="x_29e">You can use this hook for the same purposes as
+	the <literal role="hook">changegroup</literal> hook (<xref
+	  linkend="sec:hook:changegroup"/>); it's simply more
+	convenient sometimes to run a hook once per group of
 	changesets, while other times it's handier once per changeset.
       </para>
 
@@ -1580,23 +1580,23 @@
 	    ID of the newly added changeset.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2a1"><literal>source</literal>: A string.  The
-	    source of these changes.  See section <xref
+	<listitem><para id="x_2a1"><literal>source</literal>: A
+	    string.  The source of these changes.  See <xref
 	      linkend="sec:hook:sources"/> for details.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2a2"><literal>url</literal>: A URL.  The location
-	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
-	    information.
+	<listitem><para id="x_2a2"><literal>url</literal>: A URL.  The
+	    location of the remote repository, if known.  See <xref
+	      linkend="sec:hook:url"/> for more information.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2a3">See also: <literal role="hook">changegroup</literal>
-	(section <xref linkend="sec:hook:changegroup"/>) <literal
-	  role="hook">prechangegroup</literal> (section <xref
+      <para id="x_2a3">See also: <literal
+	  role="hook">changegroup</literal> (<xref
+	  linkend="sec:hook:changegroup"/>) <literal
+	  role="hook">prechangegroup</literal> (<xref
 	  linkend="sec:hook:prechangegroup"/>), <literal
-	  role="hook">pretxnchangegroup</literal> (section <xref
+	  role="hook">pretxnchangegroup</literal> (<xref
 	  linkend="sec:hook:pretxnchangegroup"/>)
       </para>
 
@@ -1624,7 +1624,7 @@
 	  </para>
 	</listitem>
 	<listitem><para id="x_2a8"><literal>source</literal>: A string.  The
-	    source of the of the operation (see section <xref
+	    source of the of the operation (see <xref
 	      linkend="sec:hook:sources"/>).  If a remote
 	    client pulled changes from this repository,
 	    <literal>source</literal> will be
@@ -1636,15 +1636,15 @@
 	    client performed.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2a9"><literal>url</literal>: A URL.  The location
-	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
-	    information.
+	<listitem><para id="x_2a9"><literal>url</literal>: A URL.  The
+	    location of the remote repository, if known.  See <xref
+	      linkend="sec:hook:url"/> for more information.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2aa">See also: <literal role="hook">preoutgoing</literal>
-	(section <xref linkend="sec:hook:preoutgoing"/>)
+      <para id="x_2aa">See also: <literal
+	  role="hook">preoutgoing</literal> (<xref
+	  linkend="sec:hook:preoutgoing"/>)
       </para>
 
     </sect2>
@@ -1674,22 +1674,22 @@
       </para>
       <itemizedlist>
 	<listitem><para id="x_2af"><literal>source</literal>: A string.  The
-	    source of these changes.  See section <xref
+	    source of these changes.  See <xref
 	      linkend="sec:hook:sources"/> for details.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2b0"><literal>url</literal>: A URL.  The location
-	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
-	    information.
+	<listitem><para id="x_2b0"><literal>url</literal>: A URL.  The
+	    location of the remote repository, if known.  See <xref
+	      linkend="sec:hook:url"/> for more information.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2b1">See also: <literal role="hook">changegroup</literal>
-	(section <xref linkend="sec:hook:changegroup"/>), <literal
-	  role="hook">incoming</literal> (section <xref
-	  linkend="sec:hook:incoming"/>), , <literal
-	  role="hook">pretxnchangegroup</literal> (section <xref
+      <para id="x_2b1">See also: <literal
+	  role="hook">changegroup</literal> (<xref
+	  linkend="sec:hook:changegroup"/>), <literal
+	  role="hook">incoming</literal> (<xref
+	  linkend="sec:hook:incoming"/>), <literal
+	  role="hook">pretxnchangegroup</literal> (<xref
 	  linkend="sec:hook:pretxnchangegroup"/>)
       </para>
 
@@ -1727,9 +1727,9 @@
 	directory will become the parents of the new changeset.
       </para>
 
-      <para id="x_2b8">See also: <literal role="hook">commit</literal> (section
-	<xref linkend="sec:hook:commit"/>), <literal
-	  role="hook">pretxncommit</literal> (section <xref
+      <para id="x_2b8">See also: <literal role="hook">commit</literal>
+	(<xref linkend="sec:hook:commit"/>), <literal
+	  role="hook">pretxncommit</literal> (<xref
 	  linkend="sec:hook:pretxncommit"/>)
       </para>
 
@@ -1749,26 +1749,25 @@
       <para id="x_2bb">Parameters to this hook:
       </para>
       <itemizedlist>
-	<listitem><para id="x_2bc"><literal>source</literal>: A string.  The
-	    source of the operation that is attempting to obtain
-	    changes from this repository (see section <xref
+	<listitem><para id="x_2bc"><literal>source</literal>: A
+	    string.  The source of the operation that is attempting to
+	    obtain changes from this repository (see <xref
 	      linkend="sec:hook:sources"/>).  See the documentation
 	    for the <literal>source</literal> parameter to the
-	    <literal role="hook">outgoing</literal> hook, in section
+	    <literal role="hook">outgoing</literal> hook, in
 	    <xref linkend="sec:hook:outgoing"/>, for possible values
-	    of
-	    this parameter.
+	    of this parameter.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2bd"><literal>url</literal>: A URL.  The location
-	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
-	    information.
+	<listitem><para id="x_2bd"><literal>url</literal>: A URL.  The
+	    location of the remote repository, if known.  See <xref
+	      linkend="sec:hook:url"/> for more information.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2be">See also: <literal role="hook">outgoing</literal> (section
-	<xref linkend="sec:hook:outgoing"/>)
+      <para id="x_2be">See also: <literal
+	  role="hook">outgoing</literal> (<xref
+	  linkend="sec:hook:outgoing"/>)
       </para>
 
     </sect2>
@@ -1800,15 +1799,16 @@
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2c4">If the tag to be created is revision-controlled, the
-	<literal role="hook">precommit</literal> and <literal
-	  role="hook">pretxncommit</literal> hooks (sections <xref
+      <para id="x_2c4">If the tag to be created is
+	revision-controlled, the <literal
+	  role="hook">precommit</literal> and <literal
+	  role="hook">pretxncommit</literal> hooks (<xref
 	  linkend="sec:hook:commit"/> and <xref
 	  linkend="sec:hook:pretxncommit"/>) will also be run.
       </para>
 
-      <para id="x_2c5">See also: <literal role="hook">tag</literal> (section
-	<xref linkend="sec:hook:tag"/>)
+      <para id="x_2c5">See also: <literal role="hook">tag</literal>
+	(<xref linkend="sec:hook:tag"/>)
       </para>
     </sect2>
     <sect2 id="sec:hook:pretxnchangegroup">
@@ -1856,23 +1856,23 @@
 	      role="hg-cmd">hg unbundle</command>.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2cc"><literal>source</literal>: A string.  The
-	    source of these changes.  See section <xref
+	<listitem><para id="x_2cc"><literal>source</literal>: A
+	    string.  The source of these changes.  See <xref
 	      linkend="sec:hook:sources"/> for details.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2cd"><literal>url</literal>: A URL.  The location
-	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
-	    information.
+	<listitem><para id="x_2cd"><literal>url</literal>: A URL.  The
+	    location of the remote repository, if known.  See <xref
+	      linkend="sec:hook:url"/> for more information.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2ce">See also: <literal role="hook">changegroup</literal>
-	(section <xref linkend="sec:hook:changegroup"/>), <literal
-	  role="hook">incoming</literal> (section <xref
+      <para id="x_2ce">See also: <literal
+	  role="hook">changegroup</literal> (<xref
+	  linkend="sec:hook:changegroup"/>), <literal
+	  role="hook">incoming</literal> (<xref
 	  linkend="sec:hook:incoming"/>), <literal
-	  role="hook">prechangegroup</literal> (section <xref
+	  role="hook">prechangegroup</literal> (<xref
 	  linkend="sec:hook:prechangegroup"/>)
       </para>
 
@@ -1919,8 +1919,9 @@
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2d6">See also: <literal role="hook">precommit</literal>
-	(section <xref linkend="sec:hook:precommit"/>)
+      <para id="x_2d6">See also: <literal
+	  role="hook">precommit</literal> (<xref
+	  linkend="sec:hook:precommit"/>)
       </para>
 
     </sect2>
@@ -1928,32 +1929,32 @@
       <title><literal role="hook">preupdate</literal>&emdash;before
 	updating or merging working directory</title>
 
-      <para id="x_2d7">This controlling hook is run before an update or merge of
-	the working directory begins.  It is run only if Mercurial's
-	normal pre-update checks determine that the update or merge
-	can proceed.  If the hook succeeds, the update or merge may
-	proceed; if it fails, the update or merge does not start.
+      <para id="x_2d7">This controlling hook is run before an update
+	or merge of the working directory begins.  It is run only if
+	Mercurial's normal pre-update checks determine that the update
+	or merge can proceed.  If the hook succeeds, the update or
+	merge may proceed; if it fails, the update or merge does not
+	start.
       </para>
 
       <para id="x_2d8">Parameters to this hook:
       </para>
       <itemizedlist>
-	<listitem><para id="x_2d9"><literal>parent1</literal>: A changeset ID.
-	    The ID of the parent that the working directory is to be
-	    updated to.  If the working directory is being merged, it
-	    will not change this parent.
+	<listitem><para id="x_2d9"><literal>parent1</literal>: A
+	    changeset ID. The ID of the parent that the working
+	    directory is to be updated to.  If the working directory
+	    is being merged, it will not change this parent.
 	  </para>
 	</listitem>
-	<listitem><para id="x_2da"><literal>parent2</literal>: A changeset ID.
-	    Only set if the working directory is being merged.  The ID
-	    of the revision that the working directory is being merged
-	    with.
+	<listitem><para id="x_2da"><literal>parent2</literal>: A
+	    changeset ID. Only set if the working directory is being
+	    merged.  The ID of the revision that the working directory
+	    is being merged with.
 	  </para>
 	</listitem></itemizedlist>
 
-      <para id="x_2db">See also: <literal role="hook">update</literal> (section
-	<xref linkend="sec:hook:update"/>)
-      </para>
+      <para id="x_2db">See also: <literal role="hook">update</literal>
+	(<xref linkend="sec:hook:update"/>)</para>
 
     </sect2>
     <sect2 id="sec:hook:tag">
@@ -1988,8 +1989,8 @@
 	  linkend="sec:hook:commit"/>) is run before this hook.
       </para>
 
-      <para id="x_2e2">See also: <literal role="hook">pretag</literal> (section
-	<xref linkend="sec:hook:pretag"/>)
+      <para id="x_2e2">See also: <literal role="hook">pretag</literal>
+	(<xref linkend="sec:hook:pretag"/>)
       </para>
 
     </sect2>
@@ -2023,7 +2024,7 @@
 	</listitem></itemizedlist>
 
       <para id="x_2e7">See also: <literal role="hook">preupdate</literal>
-	(section <xref linkend="sec:hook:preupdate"/>)
+	(<xref linkend="sec:hook:preupdate"/>)
       </para>
 
     </sect2>
--- a/en/ch10-template.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch10-template.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -107,7 +107,7 @@
       <emphasis>escape sequence</emphasis>, telling Mercurial to print
       a newline at the end of each template item.  If you omit this
       newline, Mercurial will run each piece of output together.  See
-      section <xref linkend="sec:template:escape"/> for more details
+      <xref linkend="sec:template:escape"/> for more details
       of escape sequences.</para>
 
     <para id="x_587">A template that prints a fixed string of text all the time
@@ -121,11 +121,10 @@
       been replaced in the output with the description of each
       changeset.  Every time Mercurial finds text enclosed in curly
       braces (<quote><literal>{</literal></quote> and
-      <quote><literal>}</literal></quote>), it will try to replace the braces
-      and text with the expansion of whatever is inside.  To print a
-      literal curly brace, you must escape it, as described in section
-      <xref
-	linkend="sec:template:escape"/>.</para>
+      <quote><literal>}</literal></quote>), it will try to replace the
+      braces and text with the expansion of whatever is inside.  To
+      print a literal curly brace, you must escape it, as described in
+      <xref linkend="sec:template:escape"/>.</para>
 
   </sect1>
   <sect1 id="sec:template:keyword">
@@ -149,7 +148,7 @@
 	  Date information.  The date when the changeset was
 	  committed.  This is <emphasis>not</emphasis> human-readable;
 	  you must pass it through a filter that will render it
-	  appropriately.  See section <xref
+	  appropriately.  See <xref
 	    linkend="sec:template:filter"/> for more information
 	  on filters. The date is expressed as a pair of numbers.  The
 	  first number is a Unix UTC timestamp (seconds since January
@@ -197,8 +196,7 @@
     <para id="x_596">As we noted above, the date keyword does not produce
       human-readable output, so we must treat it specially.  This
       involves using a <emphasis>filter</emphasis>, about which more
-      in section <xref
-	linkend="sec:template:filter"/>.</para>
+      in <xref linkend="sec:template:filter"/>.</para>
 
     &interaction.template.simple.datekeyword;
 
--- a/en/ch11-mq.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch11-mq.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -36,7 +36,7 @@
 
     <para id="x_3b0">When you have few changes to maintain, it is easy to manage
       a single patch using the standard <command>diff</command> and
-      <command>patch</command> programs (see section <xref
+      <command>patch</command> programs (see <xref
 	linkend="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 <quote>chunks of
@@ -241,7 +241,7 @@
       represented by one deletion and one insertion.</para>
 
     <para id="x_3c9">We will return to some of the more subtle aspects of patches
-      later (in section <xref linkend="sec:mq:adv-patch"/>), but you
+      later (in <xref linkend="sec:mq:adv-patch"/>), but you
       should have
       enough information now to use MQ.</para>
 
@@ -400,17 +400,18 @@
 	<emphasis>knows about</emphasis>, or manages, a popped patch,
 	but the patch no longer has a corresponding changeset in the
 	repository, and the working directory does not contain the
-	changes made by the patch.  Figure <xref
+	changes made by the patch.  <xref
 	  linkend="fig:mq:stack"/> illustrates
 	the difference between applied and tracked patches.</para>
 
-      <informalfigure id="fig:mq:stack">
-	<mediaobject><imageobject><imagedata
-				    fileref="mq-stack"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para id="x_3dd">Applied and
-	      unapplied patches in the MQ patch
-	      stack</para></caption></mediaobject>
-      </informalfigure>
+      <figure id="fig:mq:stack">
+	<title>Applied and unapplied patches in the MQ patch
+	  stack</title>
+	<mediaobject>
+	  <imageobject><imagedata fileref="mq-stack"/></imageobject>
+	  <textobject><phrase>XXX add text</phrase></textobject>
+	</mediaobject>
+      </figure>
 
       <para id="x_3de">You can reapply an unapplied, or popped, patch using the
 	<command role="hg-ext-mq">qpush</command> command.  This
@@ -441,8 +442,7 @@
 	  role="hg-ext-mq-cmd-qpop-opt">-a</option> option to <command
 	  role="hg-ext-mq">qpop</command> causes it to pop all applied
 	patches.  (For some more ways to push and pop many patches,
-	see section <xref linkend="sec:mq:perf"/>
-	below.)</para>
+	see <xref linkend="sec:mq:perf"/> below.)</para>
 
 &interaction.mq.tutorial.qpush-a;
 
@@ -700,8 +700,7 @@
       <para id="x_3fa">If your patch <emphasis>used to</emphasis> apply cleanly,
 	and no longer does because you've changed the underlying code
 	that your patches are based on, Mercurial Queues can help; see
-	section <xref
-	  linkend="sec:mq:merge"/> for details.</para>
+	<xref linkend="sec:mq:merge"/> for details.</para>
 
       <para id="x_3fb">Unfortunately, there aren't any great techniques for
 	dealing with rejected hunks.  Most often, you'll need to view
@@ -941,7 +940,7 @@
 	  latest series of changes?</para>
 	<programlisting>hg email qbase:qtip</programlisting>
 	<para id="x_41c">  (Don't know what <quote>patchbombing</quote> is?  See
-	  section <xref linkend="sec:hgext:patchbomb"/>.)</para>
+	  <xref linkend="sec:hgext:patchbomb"/>.)</para>
       </listitem>
       <listitem><para id="x_41d">Need to see all of the patches since
 	  <literal>foo.patch</literal> that have touched files in a
@@ -980,7 +979,7 @@
 	    role="hg-ext-mq">qpush</command> it again, the changeset
 	  that represents the patch after the pop/push will have a
 	  <emphasis>different identity</emphasis> than the changeset
-	  that represented the hash beforehand.  See section <xref
+	  that represented the hash beforehand.  See <xref
 	    linkend="sec:mqref:cmd:qpush"/> for
 	  information as to why this is.</para>
       </listitem>
@@ -1132,7 +1131,7 @@
       hundreds of files across dozens of directories, a single
       invocation of <command>filterdiff</command> can generate a
       smaller patch that only touches files whose names match a
-      particular glob pattern.  See section <xref
+      particular glob pattern.  See <xref
 	linkend="mq-collab:tips:interdiff"/> for another
       example.</para>
 
@@ -1170,7 +1169,7 @@
 
     <para id="x_436">For this reason, it is very much worth investing a little
       time to learn how to use some of the third-party tools I
-      described in section <xref linkend="sec:mq:tools"/>,
+      described in <xref linkend="sec:mq:tools"/>,
       particularly
       <command>diffstat</command> and <command>filterdiff</command>.
       The former will give you a quick idea of what changes your patch
@@ -1292,7 +1291,7 @@
 
       <para id="x_447">Once you have this hunk, you can concatenate it onto the
 	end of your destination patch and continue with the remainder
-	of section <xref linkend="sec:mq:combine"/>.</para>
+	of <xref linkend="sec:mq:combine"/>.</para>
 
     </sect2>
   </sect1>
--- a/en/ch12-mq-collab.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch12-mq-collab.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -435,7 +435,7 @@
 
       <para id="x_19a">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 <xref linkend="sec:mq:repo"/>.  If you do
+	discussed in <xref linkend="sec:mq:repo"/>.  If you do
 	so, you'll quickly
 	discover that using the <command role="hg-cmd">hg
 	  diff</command> command to look at the history of changes to
@@ -504,7 +504,7 @@
 
       <para id="x_1a2">The <literal role="hg-ext">extdiff</literal> extension is
 	useful for more than merely improving the presentation of MQ
-	patches.  To read more about it, go to section <xref
+	patches.  To read more about it, go to <xref
 	  linkend="sec:hgext:extdiff"/>.</para>
 
     </sect2>
--- a/en/ch13-hgext.xml	Thu Mar 26 21:07:39 2009 -0700
+++ b/en/ch13-hgext.xml	Thu Mar 26 21:22:03 2009 -0700
@@ -15,13 +15,13 @@
     <emphasis>plugins</emphasis>).  We've already discussed a few of
     these extensions in earlier chapters.</para>
   <itemizedlist>
-    <listitem><para id="x_500">Section <xref linkend="sec:tour-merge:fetch"/>
+    <listitem><para id="x_500"><xref linkend="sec:tour-merge:fetch"/>
 	covers the <literal role="hg-ext">fetch</literal> extension;
 	this combines pulling new changes and merging them with local
 	changes into a single command, <command
 	  role="hg-ext-fetch">fetch</command>.</para>
     </listitem>
-    <listitem><para id="x_501">In chapter <xref linkend="chap:hook"/>, we covered
+    <listitem><para id="x_501">In <xref linkend="chap:hook"/>, we covered
 	several extensions that are useful for hook-related
 	functionality: <literal role="hg-ext">acl</literal> adds
 	access control lists; <literal
@@ -32,10 +32,10 @@
     </listitem>
     <listitem><para id="x_502">The Mercurial Queues patch management extension is
 	so invaluable that it merits two chapters and an appendix all
-	to itself. Chapter <xref linkend="chap:mq"/> covers the
-	basics; chapter <xref
+	to itself. <xref linkend="chap:mq"/> covers the
+	basics; <xref
 	  linkend="chap:mq-collab"/> discusses advanced topics;
-	and appendix <xref linkend="chap:mqref"/> goes into detail on
+	and <xref linkend="chap:mqref"/> goes into detail on
 	each
 	command.</para>
     </listitem></itemizedlist>
@@ -45,7 +45,7 @@
     machinery you'll need to know about if you want to write an
     extension of your own.</para>
   <itemizedlist>
-    <listitem><para id="x_504">In section <xref linkend="sec:hgext:inotify"/>,
+    <listitem><para id="x_504">In <xref linkend="sec:hgext:inotify"/>,
 	we'll discuss the possibility of <emphasis>huge</emphasis>
 	performance improvements using the <literal
 	  role="hg-ext">inotify</literal> extension.</para>
@@ -183,7 +183,7 @@
       </listitem>
       <listitem><para id="x_517">Make sure that you have the Mercurial Queues
 	  extension, <literal role="hg-ext">mq</literal>, enabled.  If
-	  you've never used MQ, read section <xref
+	  you've never used MQ, read <xref
 	    linkend="sec:mq:start"/> to get started
 	  quickly.</para>
       </listitem>
@@ -353,7 +353,7 @@
       you can easily work around this with a little scripting.  For an
       example of such scripting in action with the <literal
 	role="hg-ext">mq</literal> extension and the
-      <command>interdiff</command> command, see section <xref
+      <command>interdiff</command> command, see <xref
 	linkend="mq-collab:tips:interdiff"/>.</para>
 
     <sect2>
@@ -502,7 +502,7 @@
 	    use.</para>
 	</listitem>
 	<listitem><para id="x_53e">The default behaviour is to send unified diffs
-	    (see section <xref linkend="sec:mq:patch"/> for a
+	    (see <xref linkend="sec:mq:patch"/> for a
 	    description of the
 	    format), one per message.  You can send a binary bundle
 	    instead with the <option