# HG changeset patch
# User Dongsheng Song <dongsheng.song@gmail.com>
# Date 1237257825 -28800
# Node ID a13813534ccdb9277456958064f99e9b86ed82ac
# Parent  1a3d882149fda80474ecc9f473a35887e0881e31
Fix all xref to figs

diff -r 1a3d882149fd -r a13813534ccd en/ch02-tour-basic.xml
--- a/en/ch02-tour-basic.xml	Mon Mar 16 17:49:05 2009 +0800
+++ b/en/ch02-tour-basic.xml	Tue Mar 17 10:43:45 2009 +0800
@@ -250,7 +250,8 @@
 	log</command> is purely a summary; it is missing a lot of
       detail.</para>
 
-    <para>Figure <xref linkend="fig.tour-basic.history"/> provides a
+    <para>Figure <xref endterm="fig.tour-basic.history.caption"
+        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
@@ -262,9 +263,9 @@
       <mediaobject>
 	<imageobject><imagedata fileref="images/tour-history.png"/></imageobject>
 	<textobject><phrase>XXX add text</phrase></textobject>
-	<caption><para>Graphical history of the <filename
-	      class="directory">hello</filename>
-	    repository</para></caption>
+	<caption><para id="fig.tour-basic.history.caption">Graphical history of
+	    the <filename class="directory">hello</filename> repository</para>
+	</caption>
       </mediaobject>
     </informalfigure>
 
@@ -775,7 +776,8 @@
       &interaction.tour.parents;
 
       <para>If you look back at figure <xref
-	  linkend="fig.tour-basic.history"/>,
+	   endterm="fig.tour-basic.history.caption" 
+	   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
 	parent, and the node that the arrow leads
diff -r 1a3d882149fd -r a13813534ccd en/ch03-tour-merge.xml
--- a/en/ch03-tour-merge.xml	Mon Mar 16 17:49:05 2009 +0800
+++ b/en/ch03-tour-merge.xml	Tue Mar 17 10:43:45 2009 +0800
@@ -37,7 +37,7 @@
     <para>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 figure <xref endterm="fig.tour-merge.sep-repos.caption"
 	linkend="fig.tour-merge.sep-repos"/>.</para>
 
     &interaction.tour.merge.cat;
@@ -46,7 +46,8 @@
       <mediaobject>
 	<imageobject><imagedata fileref="images/tour-merge-sep-repos.png"/></imageobject>
 	<textobject><phrase>XXX add text</phrase></textobject>
-	<caption><para>Divergent recent histories of the <filename
+	<caption><para id="fig.tour-merge.sep-repos.caption">Divergent recent
+	  histories of the <filename
 	      class="directory">my-hello</filename> and <filename
 	      class="directory">my-new-hello</filename>
 	    repositories</para></caption>
@@ -72,23 +73,24 @@
 	head.</para>
 
       <informalfigure id="fig.tour-merge.pull">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/tour-merge-pull.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject>
-	  <caption><para>Repository contents after pulling from
-	      <filename class="directory">my-hello</filename> into
-	      <filename
-		class="directory">my-new-hello</filename></para></caption>
+	<mediaobject>
+	  <imageobject><imagedata fileref="images/tour-merge-pull.png"/></imageobject>
+	  <textobject><phrase>XXX add text</phrase></textobject>
+	  <caption><para id="fig.tour-merge.pull.caption">Repository contents after
+	    pulling from <filename class="directory">my-hello</filename> into
+	    <filename class="directory">my-new-hello</filename></para></caption>
 	</mediaobject>
       </informalfigure>
 
-      <para>In figure <xref linkend="fig.tour-merge.pull"/>, you can
+      <para>In figure <xref endterm="fig.tour-merge.pull.caption"
+        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
+	  endterm="fig.tour-merge.sep-repos.caption" 
 	  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
@@ -119,12 +121,11 @@
       &interaction.tour.merge.merge;
 
       <informalfigure id="fig.tour-merge.merge">
-
-	<mediaobject><imageobject><imagedata
-				    fileref="images/tour-merge-merge.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject>
-	  <caption><para>Working directory and repository during
-	      merge, and following commit</para></caption>
+	<mediaobject>
+	  <imageobject><imagedata fileref="images/tour-merge-merge.png"/></imageobject>
+	  <textobject><phrase>XXX add text</phrase></textobject>
+	  <caption><para id="fig.tour-merge.merge.caption">Working directory and
+	      repository during merge, and following commit</para></caption>
 	</mediaobject>
       </informalfigure>
 
@@ -154,7 +155,7 @@
 
       &interaction.tour.merge.tip;
 
-      <para>In figure <xref
+      <para>In figure <xref endterm="fig.tour-merge.merge.caption"
 	  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
@@ -174,16 +175,18 @@
       to decide how to reconcile the different changes into something
       coherent.</para>
 
-    <informalfigure>
-
-      <mediaobject id="fig.tour-merge.conflict">
-	<imageobject><imagedata fileref="images/tour-merge-conflict.png"/></imageobject>
-	<textobject><phrase>XXX add text</phrase></textobject>
-	<caption><para>Conflicting changes to a
-	    document</para></caption>      </mediaobject>
+    <informalfigure id="fig.tour-merge.conflict">
+      <mediaobject>
+        <imageobject><imagedata fileref="images/tour-merge-conflict.png"/>
+        </imageobject>
+        <textobject><phrase>XXX add text</phrase></textobject>
+        <caption><para id="fig.tour-merge.conflict.caption">Conflicting
+          changes to a document</para></caption>
+      </mediaobject>
     </informalfigure>
 
-    <para>Figure <xref linkend="fig.tour-merge.conflict"/> illustrates
+    <para>Figure <xref endterm="fig.tour-merge.conflict.caption"
+      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
@@ -213,7 +216,8 @@
 	<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
+	figure <xref endterm="fig.tour-merge.kdiff3.caption"
+	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
@@ -244,12 +248,14 @@
 	corresponding sections of their respective files.</para>
 
       <informalfigure id="fig.tour-merge.kdiff3">
-	<mediaobject><imageobject><imagedata width="100%"
-				    fileref="images/kdiff3.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject>
-	  <caption><para>Using <command>kdiff3</command> to merge
-	      versions of a file</para></caption>
-	</mediaobject>
+        <mediaobject>
+          <imageobject><imagedata width="100%" fileref="images/kdiff3.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.tour-merge.kdiff3.caption">Using
+            <command>kdiff3</command> to merge versions of a file</para>
+          </caption>
+        </mediaobject>
       </informalfigure>
 
       <para>For each conflicting portion of the file, we can choose to
@@ -270,7 +276,8 @@
       <title>A worked example</title>
 
       <para>In this example, we will reproduce the file modification
-	history of figure <xref linkend="fig.tour-merge.conflict"/>
+	history of figure <xref endterm="fig.tour-merge.conflict.caption"
+	linkend="fig.tour-merge.conflict"/>
 	above.  Let's begin by creating a repository with a base
 	version of our document.</para>
 
diff -r 1a3d882149fd -r a13813534ccd en/ch04-concepts.xml
--- a/en/ch04-concepts.xml	Mon Mar 16 17:49:05 2009 +0800
+++ b/en/ch04-concepts.xml	Tue Mar 17 10:43:45 2009 +0800
@@ -47,15 +47,17 @@
 	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
+	  endterm="fig.concepts.filelog.caption"
 	  linkend="fig.concepts.filelog"/>.</para>
 
       <informalfigure id="fig.concepts.filelog">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/filelog.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject>
-	  <caption><para>Relationships between files in working
-	      directory and filelogs in
-	      repository</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/filelog.png"/></imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.filelog.caption">Relationships between
+            files in working directory and filelogs in repository</para>
+          </caption>
+        </mediaobject>
       </informalfigure>
 
     </sect2>
@@ -97,14 +99,16 @@
 	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
-	<xref linkend="fig.concepts.metadata"/>.</para>
+	<xref endterm="fig.concepts.metadata.caption"
+	  linkend="fig.concepts.metadata"/>.</para>
 
       <informalfigure id="fig.concepts.metadata">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/metadata.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Metadata
-	      relationships</para></caption>
-	</mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/metadata.png"/></imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.metadata.caption">Metadata
+            relationships</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>As the illustration shows, there is
@@ -185,11 +189,12 @@
 	longer it takes to reconstruct a particular revision.</para>
 
       <informalfigure id="fig.concepts.snapshot">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/snapshot.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Snapshot of
-	      a revlog, with incremental
-	      deltas</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/snapshot.png"/></imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.snapshot.caption">Snapshot of
+            a revlog, with incremental deltas</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>The innovation that Mercurial applies to this problem is
@@ -201,7 +206,8 @@
 	quickly.  This approach works so well that it has since been
 	copied by several other revision control systems.</para>
 
-      <para>Figure <xref linkend="fig.concepts.snapshot"/> illustrates
+      <para>Figure <xref endterm="fig.concepts.snapshot.caption"
+          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 +279,8 @@
       <quote>there is no parent here</quote>.  This hash is simply a
       string of zeroes.</para>
 
-    <para>In figure <xref linkend="fig.concepts.revlog"/>, you can see
+    <para>In figure <xref endterm="fig.concepts.revlog.caption"
+        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
@@ -289,9 +296,12 @@
       revision IDs in its parent slots.</para>
 
     <informalfigure id="fig.concepts.revlog">
-      <mediaobject><imageobject><imagedata
-				  fileref="images/revlog.png"/></imageobject><textobject><phrase>XXX 
-	    add text</phrase></textobject></mediaobject>
+      <mediaobject>
+        <imageobject><imagedata fileref="images/revlog.png"/></imageobject>
+        <textobject><phrase>XXX add text</phrase></textobject>        
+	<caption><para id="fig.concepts.revlog.caption">Revision in revlog</para>
+	</caption>
+      </mediaobject>
     </informalfigure>
 
   </sect1>
@@ -338,25 +348,29 @@
 	  changeset</emphasis> when you perform a commit.</para>
 
       <informalfigure id="fig.concepts.wdir">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/wdir.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>The working
-	      directory can have two
-	      parents</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/wdir.png"/></imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.wdir.caption">The working
+            directory can have two parents</para></caption>
+        </mediaobject>
       </informalfigure>
 
-      <para>Figure <xref linkend="fig.concepts.wdir"/> shows the
+      <para>Figure <xref endterm="fig.concepts.wdir.caption"
+          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
 	repository that has no children.</para>
 
       <informalfigure id="fig.concepts.wdir-after-commit">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/wdir-after-commit.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>The working
-	      directory gains new parents after a
-	      commit</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/wdir-after-commit.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.wdir-after-commit.caption">The working
+            directory gains new parents after a commit</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>It's useful to think of the working directory as
@@ -370,7 +384,8 @@
       <para>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"/>.
+	in figure <xref endterm="fig.concepts.wdir-after-commit.caption"
+	  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
@@ -389,14 +404,17 @@
 	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>
+	figure <xref endterm="fig.concepts.wdir-pre-branch.caption"
+	  linkend="fig.concepts.wdir-pre-branch"/>.</para>
 
       <informalfigure id="fig.concepts.wdir-pre-branch">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/wdir-pre-branch.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>The working
-	      directory, updated to an older
-	      changeset</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/wdir-pre-branch.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.wdir-pre-branch.caption">The working
+            directory, updated to an older changeset</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>Having updated the working directory to an older
@@ -408,14 +426,17 @@
 	contains two changesets that have no children; we call these
 	<emphasis>heads</emphasis>.  You can see the structure that
 	this creates in figure <xref
+	  endterm="fig.concepts.wdir-branch.caption"
 	  linkend="fig.concepts.wdir-branch"/>.</para>
 
       <informalfigure id="fig.concepts.wdir-branch">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/wdir-branch.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>After a
-	      commit made while synced to an older
-	      changeset</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/wdir-branch.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.wdir-branch.caption">After a
+            commit made while synced to an older changeset</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <note>
@@ -449,13 +470,17 @@
 	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
+	  endterm="fig.concepts.wdir-merge.caption" 
 	  linkend="fig.concepts.wdir-merge"/>.</para>
 
       <informalfigure id="fig.concepts.wdir-merge">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/wdir-merge.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Merging two
-	      heads</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/wdir-merge.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.concepts.wdir-merge.caption">Merging two
+            heads</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>Mercurial also has to modify the working directory, to
@@ -582,8 +607,8 @@
 
       <para>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
+	recall figure <xref endterm="fig.concepts.metadata.caption"
+	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>
diff -r 1a3d882149fd -r a13813534ccd en/ch06-collab.xml
--- a/en/ch06-collab.xml	Mon Mar 16 17:49:05 2009 +0800
+++ b/en/ch06-collab.xml	Tue Mar 17 10:43:45 2009 +0800
@@ -271,10 +271,13 @@
 	isolated from developments on other branches.</para>
 
       <informalfigure id="fig.collab.feature-branches">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/feature-branches.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Feature
-	      branches</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/feature-branches.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.collab.feature-branches.caption">Feature
+            branches</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>When a particular feature is deemed to be in suitable
diff -r 1a3d882149fd -r a13813534ccd en/ch09-undo.xml
--- a/en/ch09-undo.xml	Mon Mar 16 17:49:05 2009 +0800
+++ b/en/ch09-undo.xml	Tue Mar 17 10:43:45 2009 +0800
@@ -354,18 +354,21 @@
 	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
+	  endterm="fig.undo.backout.caption" linkend="fig.undo.backout"/>,
+	which presents a graphical
 	view of the change history.  As you can see, the history is
 	nice and linear.</para>
 
       <informalfigure id="fig.undo.backout">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/undo-simple.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Backing out
-	      a change using the <command role="hg-cmd">hg
-		backout</command>
-	      command</para></caption></mediaobject>
-	
+        <mediaobject>
+          <imageobject><imagedata fileref="images/undo-simple.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.undo.backout.caption">Backing out
+            a change using the 
+            <command role="hg-cmd">hg backout</command>
+            command</para></caption>
+      </mediaobject>
       </informalfigure>
 
     </sect2>
@@ -393,6 +396,7 @@
       &interaction.backout.non-tip.cat;
 
       <para>As the graphical history in figure <xref
+	  endterm="fig.undo.backout-non-tip.caption"
 	  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
@@ -407,12 +411,14 @@
 	second merge automatically!</para>
 
       <informalfigure id="fig.undo.backout-non-tip">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/undo-non-tip.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Automated
-	      backout of a non-tip change using the <command
-		role="hg-cmd">hg backout</command>
-	      command</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/undo-non-tip.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.undo.backout-non-tip.caption">Automated
+            backout of a non-tip change using the
+            <command role="hg-cmd">hg backout</command> command</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>The result is that you end up <quote>back where you
@@ -465,6 +471,7 @@
 
       <para>Again, it's easier to see what has happened by looking at
 	a graph of the revision history, in figure <xref
+	  endterm="fig.undo.backout-manual.caption"
 	  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
@@ -472,13 +479,14 @@
 	box-shaped).</para>
 
       <informalfigure id="fig.undo.backout-manual">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/undo-manual.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Backing out
-	      a change using the <command role="hg-cmd">hg
-		backout</command>
-	      command</para></caption></mediaobject>
-	
+        <mediaobject>
+          <imageobject><imagedata fileref="images/undo-manual.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.undo.backout-manual.caption">Backing out a
+            change using the <command role="hg-cmd">hg backout</command>
+            command</para></caption>
+        </mediaobject>
       </informalfigure>
 
       <para>After the <command role="hg-cmd">hg backout</command>
@@ -509,14 +517,17 @@
 
       <para>Afterwards, the graphical history of our repository looks
 	like figure
-	<xref linkend="fig.undo.backout-manual-merge"/>.</para>
+	<xref endterm="fig.undo.backout-manual-merge.caption"
+	  linkend="fig.undo.backout-manual-merge"/>.</para>
 
       <informalfigure id="fig.undo.backout-manual-merge">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/undo-manual-merge.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Manually
-	      merging a backout change</para></caption></mediaobject>
-	
+        <mediaobject>
+          <imageobject><imagedata fileref="images/undo-manual-merge.png"/>
+          </imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.undo.backout-manual-merge.caption">Manually
+            merging a backout change</para></caption>
+        </mediaobject>
       </informalfigure>
 
     </sect2>
diff -r 1a3d882149fd -r a13813534ccd en/ch12-mq.xml
--- a/en/ch12-mq.xml	Mon Mar 16 17:49:05 2009 +0800
+++ b/en/ch12-mq.xml	Tue Mar 17 10:43:45 2009 +0800
@@ -400,15 +400,16 @@
 	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
-	  linkend="fig.mq.stack"/> illustrates
+	  endterm="fig.mq.stack.caption" linkend="fig.mq.stack"/> illustrates
 	the difference between applied and tracked patches.</para>
 
       <informalfigure id="fig.mq.stack">
-	<mediaobject><imageobject><imagedata
-				    fileref="images/mq-stack.png"/></imageobject><textobject><phrase>XXX 
-	      add text</phrase></textobject><caption><para>Applied and
-	      unapplied patches in the MQ patch
-	      stack</para></caption></mediaobject>
+        <mediaobject>
+          <imageobject><imagedata fileref="images/mq-stack.png"/></imageobject>
+          <textobject><phrase>XXX add text</phrase></textobject>
+          <caption><para id="fig.mq.stack.caption">Applied and unapplied patches
+            in the MQ patch stack</para></caption>
+          </mediaobject>
       </informalfigure>
 
       <para>You can reapply an unapplied, or popped, patch using the