# HG changeset patch
# User Dongsheng Song <dongsheng.song@gmail.com>
# Date 1236844299 -28800
# Node ID cfdb601a3c8bf12ab71a7bbff71cf333b480dc4c
# Parent  3c5e1c03cc3ef5ec9e9b4bd9a87ef8ebe5578675
Fix imagedata fileref in xml files, and replace ':' with '.' in id attribute

diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/00book.xml
--- a/en/00book.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/00book.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
- "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+ "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
 [
 <!-- Below are references to files in this directory. -->
 
@@ -39,6 +39,11 @@
 
 <book id="hg">
   <title>Mercurial: The Definitive Guide</title>
+  
+  <!-- hg parents &#x2d;&#x2d;template '{node|short} ({date|shortdate})' 
+  <subtitle>Compiled from 8a1d3f1aff17 (2009-03-10)</subtitle>
+  -->
+  <subtitle>Compiled from $rev_id$</subtitle>
   <bookinfo>
     <authorgroup>
       <author>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/appA-cmdref.xml
--- a/en/appA-cmdref.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/appA-cmdref.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -12,7 +12,7 @@
 
 <para>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 section <xref linkend="sec.mq.patch"/>.</para>
 
 <para>By default, this command does not print diffs for files that Mercurial
 considers to contain binary data.  To control this behaviour, see the
@@ -158,7 +158,7 @@
 <sect2>
 <title>Tips and tricks</title>
 
-<sect3 id="cmdref:diff-vs-status">
+<sect3 id="cmdref.diff-vs-status">
 <title>Why do the results of <command role="hg-cmd">hg diff</command> and <command role="hg-cmd">hg status</command> differ?</title>
 
 <para>When you run the <command role="hg-cmd">hg status</command> command, you'll see a list of files
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/appB-mq-ref.xml
--- a/en/appB-mq-ref.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/appB-mq-ref.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,10 +1,10 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<appendix id="chap:mqref">
+<appendix id="chap.mqref">
   <?dbhtml filename="mercurial-queues-reference.html"?>
   <title>Mercurial Queues reference</title>
 
-  <sect1 id="sec:mqref:cmdref">
+  <sect1 id="sec.mqref.cmdref">
     <title>MQ command reference</title>
 
     <para>For an overview of the commands provided by MQ, use the
@@ -295,7 +295,7 @@
 	  role="hg-ext-mq">qpop</command>.</para>
 
     </sect2>
-    <sect2 id="sec:mqref:cmd:qpush">
+    <sect2 id="sec.mqref.cmd.qpush">
       <title><command role="hg-ext-mq">qpush</command>&emdash;push
 	patches onto the stack</title>
 
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/appC-srcinstall.xml
--- a/en/appC-srcinstall.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/appC-srcinstall.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,10 +1,10 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<appendix id="chap:srcinstall">
+<appendix id="chap.srcinstall">
   <?dbhtml filename="installing-mercurial-from-source.html"?>
   <title>Installing Mercurial from source</title>
 
-  <sect1 id="sec:srcinstall:unixlike">
+  <sect1 id="sec.srcinstall.unixlike">
     <title>On a Unix-like system</title>
 
     <para>If you are using a Unix-like system that has a sufficiently
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/appD-license.xml
--- a/en/appD-license.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/appD-license.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<appendix id="cha:opl">
+<appendix id="cha.opl">
   <?dbhtml filename="open-publication-license.html"?>
   <title>Open Publication License</title>
 
@@ -32,7 +32,7 @@
 
     <para>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>
+      section <xref linkend="sec.opl.options"/>).</para>
 
     <para>Commercial redistribution of Open Publication-licensed
       material is permitted.</para>
@@ -133,7 +133,7 @@
       </listitem></orderedlist>
 
   </sect1>
-  <sect1 id="sec:opl:options">
+  <sect1 id="sec.opl.options">
     <title>License options</title>
 
     <para>The author(s) and/or publisher of an Open
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch00-preface.xml
--- a/en/ch00-preface.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch00-preface.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<preface id="chap:preface">
+<preface id="chap.preface">
   <title>Preface</title>
 
   <para>Distributed revision control is a relatively new territory,
@@ -51,7 +51,7 @@
       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
-	id="sec:undo:bisect"/>, for instance.</para>
+	id="sec.undo.bisect"/>, for instance.</para>
 
     <para>So when you're reading examples, don't place too much weight
       on the dates or times you see in the output of commands.  But
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch01-intro.xml
--- a/en/ch01-intro.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch01-intro.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:intro">
+<chapter id="chap.intro">
   <?dbhtml filename="introduction.html"?>
   <title>Introduction</title>
 
@@ -50,7 +50,7 @@
 	    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
-	      linkend="sec:undo:bisect"/> for details).</para></listitem>
+	      linkend="sec.undo.bisect"/> for details).</para></listitem>
 	<listitem><para>It will help you to work simultaneously on,
 	    and manage the drift between, multiple versions of your
 	    project.</para></listitem></itemizedlist>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch02-tour-basic.xml
--- a/en/ch02-tour-basic.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch02-tour-basic.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,10 +1,10 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:tour-basic">
+<chapter id="chap.tour-basic">
   <?dbhtml filename="a-tour-of-mercurial-the-basics.html"?>
   <title>A tour of Mercurial: the basics</title>
 
-  <sect1 id="sec:tour:install">
+  <sect1 id="sec.tour.install">
     <title>Installing Mercurial on your system</title>
 
     <para>Prebuilt binary packages of Mercurial are available for
@@ -250,7 +250,7 @@
 	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 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
@@ -258,9 +258,9 @@
       several times in this chapter and the chapter that
       follows.</para>
 
-    <informalfigure id="fig:tour-basic:history">
+    <informalfigure id="fig.tour-basic.history">
       <mediaobject>
-	<imageobject><imagedata fileref="tour-history"/></imageobject>
+	<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>
@@ -361,7 +361,7 @@
 	<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
+	see section <xref linkend="sec.mq.patch"/> for an
 	overview).</para>
 
       &interaction.tour.log-vp;
@@ -519,7 +519,7 @@
 	    <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
-	      linkend="sec:tour-basic:username"/>
+	      linkend="sec.tour-basic.username"/>
 	    below.</para></listitem>
 	<listitem><para>If you have set the <envar>EMAIL</envar>
 	    environment variable, this will be used
@@ -543,7 +543,7 @@
 	and most robust way to set a username for yourself is by
 	creating a <filename role="special">.hgrc</filename> file; see
 	below for details.</para>
-      <sect3 id="sec:tour-basic:username">
+      <sect3 id="sec.tour-basic.username">
 	<title>Creating a Mercurial configuration file</title>
 
 	<para>To set a user name, use your favourite editor
@@ -684,7 +684,7 @@
 	look at a few ways that we can propagate this change into
 	other repositories.</para>
 
-    <sect2 id="sec:tour:pull">
+    <sect2 id="sec.tour.pull">
       <title>Pulling changes from another repository</title>
       <para>To get started, let's clone our original
 	  <filename class="directory">hello</filename> repository,
@@ -734,7 +734,7 @@
       <para>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
+	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
 	  role="hg-cmd">hg pull</command> does not (by default) touch
@@ -761,7 +761,7 @@
 
       <para>If you look back at the output of <command
 	  role="hg-cmd">hg pull</command> in section <xref
-	    linkend="sec:tour:pull"/> when we ran it without <option
+	    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
 	update the working directory:</para>
@@ -775,7 +775,7 @@
       &interaction.tour.parents;
 
       <para>If you look back at figure <xref
-	  linkend="fig:tour-basic:history"/>,
+	  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 3c5e1c03cc3e -r cfdb601a3c8b en/ch03-tour-merge.xml
--- a/en/ch03-tour-merge.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch03-tour-merge.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:tour-merge">
+<chapter id="chap.tour-merge">
   <?dbhtml filename="a-tour-of-mercurial-merging-work.html"?>
   <title>A tour of Mercurial: merging work</title>
 
@@ -38,13 +38,13 @@
       <filename>hello.c</filename> with different contents.  The
       histories of the two repositories have also diverged, as
       illustrated in figure <xref
-	linkend="fig:tour-merge:sep-repos"/>.</para>
+	linkend="fig.tour-merge.sep-repos"/>.</para>
 
     &interaction.tour.merge.cat;
 
-    <informalfigure id="fig:tour-merge:sep-repos">
+    <informalfigure id="fig.tour-merge.sep-repos">
       <mediaobject>
-	<imageobject><imagedata fileref="tour-merge-sep-repos"/></imageobject>
+	<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
 	      class="directory">my-hello</filename> and <filename
@@ -71,9 +71,9 @@
 	children, but a repository can contain more than one
 	head.</para>
 
-      <informalfigure id="fig:tour-merge:pull">
+      <informalfigure id="fig.tour-merge.pull">
 	<mediaobject><imageobject><imagedata
-				    fileref="tour-merge-pull"/></imageobject><textobject><phrase>XXX 
+				    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
@@ -82,14 +82,14 @@
 	</mediaobject>
       </informalfigure>
 
-      <para>In figure <xref linkend="fig:tour-merge:pull"/>, you can
+      <para>In figure <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
-	  linkend="fig:tour-merge:sep-repos"/>, we can see that the
+	  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
 	changed.  (This, incidentally, is a fine example of why it's
@@ -118,10 +118,10 @@
 
       &interaction.tour.merge.merge;
 
-      <informalfigure id="fig:tour-merge:merge">
+      <informalfigure id="fig.tour-merge.merge">
 
 	<mediaobject><imageobject><imagedata
-				    fileref="tour-merge-merge"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -155,7 +155,7 @@
       &interaction.tour.merge.tip;
 
       <para>In figure <xref
-	  linkend="fig:tour-merge:merge"/>, you can see a
+	  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
 	happens.  During the merge, the working directory has two
@@ -176,14 +176,14 @@
 
     <informalfigure>
 
-      <mediaobject id="fig:tour-merge:conflict">
-	<imageobject><imagedata fileref="tour-merge-conflict"/></imageobject>
+      <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>
 
-    <para>Figure <xref linkend="fig:tour-merge:conflict"/> illustrates
+    <para>Figure <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
@@ -213,7 +213,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
+	figure <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
@@ -243,9 +243,9 @@
 	in any of them, the others are updated to display the
 	corresponding sections of their respective files.</para>
 
-      <informalfigure id="fig:tour-merge:kdiff3">
-	<mediaobject><imageobject><imagedata
-				    fileref="kdiff3"/></imageobject><textobject><phrase>XXX 
+      <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>
@@ -270,7 +270,7 @@
       <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 linkend="fig.tour-merge.conflict"/>
 	above.  Let's begin by creating a repository with a base
 	version of our document.</para>
 
@@ -331,7 +331,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:tour-merge:fetch">
+  <sect1 id="sec.tour-merge.fetch">
     <title>Simplifying the pull-merge-commit sequence</title>
 
     <para>The process of merging changes as outlined above is
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch04-concepts.xml
--- a/en/ch04-concepts.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch04-concepts.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:concepts">
+<chapter id="chap.concepts">
   <?dbhtml filename="behind-the-scenes.html"?>
   <title>Behind the scenes</title>
 
@@ -47,11 +47,11 @@
 	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
-	  linkend="fig:concepts:filelog"/>.</para>
+	  linkend="fig.concepts.filelog"/>.</para>
 
-      <informalfigure id="fig:concepts:filelog">
+      <informalfigure id="fig.concepts.filelog">
 	<mediaobject><imageobject><imagedata
-				    fileref="filelog"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/filelog.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject>
 	  <caption><para>Relationships between files in working
 	      directory and filelogs in
@@ -97,11 +97,11 @@
 	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 linkend="fig.concepts.metadata"/>.</para>
 
-      <informalfigure id="fig:concepts:metadata">
+      <informalfigure id="fig.concepts.metadata">
 	<mediaobject><imageobject><imagedata
-				    fileref="metadata"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/metadata.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject><caption><para>Metadata
 	      relationships</para></caption>
 	</mediaobject>
@@ -145,7 +145,7 @@
 	doesn't need to treat text as special.</para>
 
     </sect2>
-    <sect2 id="sec:concepts:txn">
+    <sect2 id="sec.concepts.txn">
       <title>Safe operation</title>
 
       <para>Mercurial only ever <emphasis>appends</emphasis> data to
@@ -184,9 +184,9 @@
 	file accumulates, the more revisions you must read, hence the
 	longer it takes to reconstruct a particular revision.</para>
 
-      <informalfigure id="fig:concepts:snapshot">
+      <informalfigure id="fig.concepts.snapshot">
 	<mediaobject><imageobject><imagedata
-				    fileref="snapshot"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/snapshot.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject><caption><para>Snapshot of
 	      a revlog, with incremental
 	      deltas</para></caption></mediaobject>
@@ -201,7 +201,7 @@
 	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 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>In figure <xref linkend="fig:concepts:revlog"/>, you can see
+    <para>In figure <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
@@ -288,9 +288,9 @@
       revision that represents a merge between branches has two normal
       revision IDs in its parent slots.</para>
 
-    <informalfigure id="fig:concepts:revlog">
+    <informalfigure id="fig.concepts.revlog">
       <mediaobject><imageobject><imagedata
-				  fileref="revlog"/></imageobject><textobject><phrase>XXX 
+				  fileref="images/revlog.png"/></imageobject><textobject><phrase>XXX 
 	    add text</phrase></textobject></mediaobject>
     </informalfigure>
 
@@ -337,23 +337,23 @@
 	dirstate as <emphasis>the parents of a new
 	  changeset</emphasis> when you perform a commit.</para>
 
-      <informalfigure id="fig:concepts:wdir">
+      <informalfigure id="fig.concepts.wdir">
 	<mediaobject><imageobject><imagedata
-				    fileref="wdir"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/wdir.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject><caption><para>The working
 	      directory can have two
 	      parents</para></caption></mediaobject>
       </informalfigure>
 
-      <para>Figure <xref linkend="fig:concepts:wdir"/> shows the
+      <para>Figure <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
 	repository that has no children.</para>
 
-      <informalfigure id="fig:concepts:wdir-after-commit">
+      <informalfigure id="fig.concepts.wdir-after-commit">
 	<mediaobject><imageobject><imagedata
-				    fileref="wdir-after-commit"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -370,7 +370,7 @@
       <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 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,11 +389,11 @@
 	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 linkend="fig.concepts.wdir-pre-branch"/>.</para>
 
-      <informalfigure id="fig:concepts:wdir-pre-branch">
+      <informalfigure id="fig.concepts.wdir-pre-branch">
 	<mediaobject><imageobject><imagedata
-				    fileref="wdir-pre-branch"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -408,11 +408,11 @@
 	contains two changesets that have no children; we call these
 	<emphasis>heads</emphasis>.  You can see the structure that
 	this creates in figure <xref
-	  linkend="fig:concepts:wdir-branch"/>.</para>
+	  linkend="fig.concepts.wdir-branch"/>.</para>
 
-      <informalfigure id="fig:concepts:wdir-branch">
+      <informalfigure id="fig.concepts.wdir-branch">
 	<mediaobject><imageobject><imagedata
-				    fileref="wdir-branch"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -449,11 +449,11 @@
 	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
-	  linkend="fig:concepts:wdir-merge"/>.</para>
+	  linkend="fig.concepts.wdir-merge"/>.</para>
 
-      <informalfigure id="fig:concepts:wdir-merge">
+      <informalfigure id="fig.concepts.wdir-merge">
 	<mediaobject><imageobject><imagedata
-				    fileref="wdir-merge"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/wdir-merge.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject><caption><para>Merging two
 	      heads</para></caption></mediaobject>
       </informalfigure>
@@ -582,7 +582,7 @@
 
       <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"/>,
+	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
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch05-daily.xml
--- a/en/ch05-daily.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch05-daily.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:daily">
+<chapter id="chap.daily">
   <?dbhtml filename="mercurial-in-daily-use.html"?>
   <title>Mercurial in daily use</title>
 
@@ -274,7 +274,7 @@
       &interaction.daily.copy.merge;
 
     </sect2>
-    <sect2 id="sec:daily:why-copy">
+    <sect2 id="sec.daily.why-copy">
       <title>Why should changes follow copies?</title>
 
       <para>This behaviour, of changes to a file propagating out to
@@ -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 section <xref linkend="sec.daily.why-copy"/>, and make
 	an informed
 	decision that this behaviour is not appropriate to your
 	specific case.</para>
@@ -532,7 +532,7 @@
     <para>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
-	linkend="chap:undo"/>.</para>
+	linkend="chap.undo"/>.</para>
 
   </sect1>
 </chapter>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch06-collab.xml
--- a/en/ch06-collab.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch06-collab.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="cha:collab">
+<chapter id="cha.collab">
   <?dbhtml filename="collaborating-with-other-people.html"?>
   <title>Collaborating with other people</title>
 
@@ -47,12 +47,12 @@
       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
-	linkend="sec:collab:serve"/> below for details of how to use
+	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
-	linkend="sec:collab:cgi"/> for details of CGI
+	linkend="sec.collab.cgi"/> for details of CGI
       configuration.</para>
 
   </sect1>
@@ -120,7 +120,7 @@
 	  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
+	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
@@ -165,9 +165,9 @@
       <para>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
+	  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"/>.
+	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
@@ -270,9 +270,9 @@
 	People working on an individual branch are typically quite
 	isolated from developments on other branches.</para>
 
-      <informalfigure id="fig:collab:feature-branches">
+      <informalfigure id="fig.collab.feature-branches">
 	<mediaobject><imageobject><imagedata
-				    fileref="feature-branches"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/feature-branches.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject><caption><para>Feature
 	      branches</para></caption></mediaobject>
       </informalfigure>
@@ -408,7 +408,7 @@
 	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>
+	<xref linkend="chap.branch"/>.</para>
 
     </sect2>
   </sect1>
@@ -419,7 +419,7 @@
       serving data to your collaborators.</para>
 
   </sect1>
-  <sect1 id="sec:collab:serve">
+  <sect1 id="sec.collab.serve">
     <title>Informal sharing with <command role="hg-cmd">hg
 	serve</command></title>
 
@@ -498,7 +498,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:collab:ssh">
+  <sect1 id="sec.collab.ssh">
     <title>Using the Secure Shell (ssh) protocol</title>
 
     <para>You can pull and push changes securely over a network
@@ -859,7 +859,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:collab:cgi">
+  <sect1 id="sec.collab.cgi">
     <title>Serving over HTTP using CGI</title>
 
     <para>Depending on how ambitious you are, configuring Mercurial's
@@ -951,7 +951,7 @@
 	must not be writable by others.</para>
       <programlisting>chmod 755 ~/public_html</programlisting>
 
-      <sect3 id="sec:collab:wtf">
+      <sect3 id="sec.collab.wtf">
 	<title>What could <emphasis>possibly</emphasis> go
 	  wrong?</title>
 
@@ -1118,7 +1118,7 @@
 	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
-	  linkend="sec:collab:wtf"/>.</para>
+	  linkend="sec.collab.wtf"/>.</para>
 
       <para>The <filename role="special">hgwebdir.cgi</filename>
 	script relies on an external configuration file.  By default,
@@ -1317,7 +1317,7 @@
 	    <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.
+	    <xref linkend="chap.template"/> for details.
 	    Here, you can see how to enable the
 	    <literal>gitweb</literal> style.</para>
 	  <programlisting>[web] style = gitweb</programlisting>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch07-filenames.xml
--- a/en/ch07-filenames.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch07-filenames.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:names">
+<chapter id="chap.names">
   <?dbhtml filename="file-names-and-pattern-matching.html"?>
   <title>File names and pattern matching</title>
 
@@ -274,7 +274,7 @@
     <para>XXX.</para>
 
   </sect1>
-  <sect1 id="sec:names:case">
+  <sect1 id="sec.names.case">
     <title>Case sensitivity</title>
 
     <para>If you're working in a mixed development environment that
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch08-branch.xml
--- a/en/ch08-branch.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch08-branch.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:branch">
+<chapter id="chap.branch">
   <?dbhtml filename="managing-releases-and-branchy-development.html"?>
   <title>Managing releases and branchy development</title>
 
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch09-undo.xml
--- a/en/ch09-undo.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch09-undo.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:undo">
+<chapter id="chap.undo">
   <?dbhtml filename="finding-and-fixing-mistakes.html"?>
   <title>Finding and fixing mistakes</title>
 
@@ -27,17 +27,17 @@
 	less annoying.</para>
 
     </sect2>
-    <sect2 id="sec:undo:rollback">
+    <sect2 id="sec.undo.rollback">
       <title>Rolling back a transaction</title>
 
-      <para>In section <xref linkend="sec:concepts:txn"/>, I mentioned
+      <para>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
+	section <xref linkend="sec.undo.rollback-after-push"/> for an
 	important caveat about the use of this command.)</para>
 
       <para>Here's a mistake that I often find myself making:
@@ -111,7 +111,7 @@
 	need to undo this mistake.</para>
 
     </sect2>
-    <sect2 id="sec:undo:rollback-after-push">
+    <sect2 id="sec.undo.rollback-after-push">
       <title>Rolling back is useless once you've pushed</title>
 
       <para>The value of the <command role="hg-cmd">hg
@@ -214,7 +214,7 @@
 	  the file to its unmodified contents.</para>
       </listitem></itemizedlist>
 
-    <sect2 id="sec:undo:mgmt">
+    <sect2 id="sec.undo.mgmt">
       <title>File management errors</title>
 
       <para>The <command role="hg-cmd">hg revert</command> command is
@@ -306,7 +306,7 @@
       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
-      <xref linkend="sec:undo:aaaiiieee"/>.</para>
+      <xref linkend="sec.undo.aaaiiieee"/>.</para>
 
     <sect2>
       <title>Backing out a changeset</title>
@@ -354,13 +354,13 @@
 	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
+	  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">
+      <informalfigure id="fig.undo.backout">
 	<mediaobject><imageobject><imagedata
-				    fileref="undo-simple"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -393,7 +393,7 @@
       &interaction.backout.non-tip.cat;
 
       <para>As the graphical history in figure <xref
-	  linkend="fig:undo:backout-non-tip"/> illustrates, Mercurial
+	  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
 	commits automatically).  Before Mercurial begins the backout
@@ -406,9 +406,9 @@
       <para>% TODO: to me it looks like mercurial doesn't commit the
 	second merge automatically!</para>
 
-      <informalfigure id="fig:undo:backout-non-tip">
+      <informalfigure id="fig.undo.backout-non-tip">
 	<mediaobject><imageobject><imagedata
-				    fileref="undo-non-tip"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -465,15 +465,15 @@
 
       <para>Again, it's easier to see what has happened by looking at
 	a graph of the revision history, in figure <xref
-	  linkend="fig:undo:backout-manual"/>.  This makes it clear
+	  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
 	head to the repository (the change it committed is
 	box-shaped).</para>
 
-      <informalfigure id="fig:undo:backout-manual">
+      <informalfigure id="fig.undo.backout-manual">
 	<mediaobject><imageobject><imagedata
-				    fileref="undo-manual"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -509,11 +509,11 @@
 
       <para>Afterwards, the graphical history of our repository looks
 	like figure
-	<xref linkend="fig:undo:backout-manual-merge"/>.</para>
+	<xref linkend="fig.undo.backout-manual-merge"/>.</para>
 
-      <informalfigure id="fig:undo:backout-manual-merge">
+      <informalfigure id="fig.undo.backout-manual-merge">
 	<mediaobject><imageobject><imagedata
-				    fileref="undo-manual-merge"/></imageobject><textobject><phrase>XXX 
+				    fileref="images/undo-manual-merge.png"/></imageobject><textobject><phrase>XXX 
 	      add text</phrase></textobject><caption><para>Manually
 	      merging a backout change</para></caption></mediaobject>
 	
@@ -584,7 +584,7 @@
 	are likely to have <quote>broken the context</quote> that
 	<command>patch</command> uses to determine whether it can
 	apply a patch (if this sounds like gibberish, see <xref
-	  linkend="sec:mq:patch"/> for a
+	  linkend="sec.mq.patch"/> for a
 	discussion of the <command>patch</command> command).  Also,
 	Mercurial's merge machinery will handle files and directories
 	being renamed, permission changes, and modifications to binary
@@ -593,7 +593,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:undo:aaaiiieee">
+  <sect1 id="sec.undo.aaaiiieee">
     <title>Changes that should never have been</title>
 
     <para>Most of the time, the <command role="hg-cmd">hg
@@ -623,7 +623,7 @@
       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>
+	linkend="sec.undo.rollback"/>.</para>
 
     <para>After you've pushed a bad change to another repository, you
       <emphasis>could</emphasis> still use <command role="hg-cmd">hg
@@ -664,7 +664,7 @@
 	central repository.</para>
 
       <para>By configuring some hooks on that repository to validate
-	incoming changesets (see chapter <xref linkend="chap:hook"/>),
+	incoming changesets (see chapter <xref linkend="chap.hook"/>),
 	you can
 	automatically prevent some kinds of bad changeset from being
 	pushed to the central repository at all.  With such a
@@ -679,7 +679,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:undo:bisect">
+  <sect1 id="sec.undo.bisect">
     <title>Finding the source of a bug</title>
 
     <para>While it's all very well to be able to back out a changeset
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch10-hook.xml
--- a/en/ch10-hook.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch10-hook.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:hook">
+<chapter id="chap.hook">
   <?dbhtml filename="handling-repository-events-with-hooks.html"?>
   <title>Handling repository events with hooks</title>
 
@@ -19,7 +19,7 @@
 
     <para>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>
+      section <xref linkend="sec.hook.ref"/>.</para>
 
     <itemizedlist>
       <listitem><para><literal role="hook">changegroup</literal>: This
@@ -343,7 +343,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:hook:simple">
+  <sect1 id="sec.hook.simple">
     <title>A short tutorial on using hooks</title>
 
     <para>It is easy to write a Mercurial hook.  Let's start with a
@@ -400,11 +400,11 @@
 	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
-	  linkend="sec:hook:perm"/> for an example).
+	  linkend="sec.hook.perm"/> for an example).
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:perm">
+    <sect2 id="sec.hook.perm">
       <title>Controlling whether an activity can proceed</title>
 
       <para>In our earlier examples, we used the <literal
@@ -459,7 +459,7 @@
       message before it calls each hook.
     </para>
 
-    <sect2 id="sec:hook:lang">
+    <sect2 id="sec.hook.lang">
       <title>Choosing how your hook should run</title>
 
       <para>You can write a hook either as a normal
@@ -490,7 +490,7 @@
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:param">
+    <sect2 id="sec.hook.param">
       <title>Hook parameters</title>
 
       <para>Mercurial calls each hook with a set of well-defined
@@ -888,7 +888,7 @@
 	  </para>
 	</listitem></itemizedlist>
 
-      <sect3 id="sec:hook:bugzilla:config">
+      <sect3 id="sec.hook.bugzilla.config">
 	<title>Configuring the <literal role="hook">bugzilla</literal>
 	  hook</title>
 
@@ -1101,7 +1101,7 @@
 	</para>
 
 	<para>Recall from section <xref
-	    linkend="sec:hook:bugzilla:config"/> above that the user
+	    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>
 	  script.  The <filename>processmail</filename> script
@@ -1259,7 +1259,7 @@
 	      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
+		linkend="sec.hook.sources"/> for the sources you can
 	      specify here.
 	    </para>
 	  </listitem></itemizedlist>
@@ -1318,7 +1318,7 @@
       </sect3>
     </sect2>
   </sect1>
-  <sect1 id="sec:hook:ref">
+  <sect1 id="sec.hook.ref">
     <title>Information for writers of hooks</title>
 
     <sect2>
@@ -1426,7 +1426,7 @@
 	transferred to or from.
       </para>
 
-      <sect3 id="sec:hook:sources">
+      <sect3 id="sec.hook.sources">
 	<title>Sources of changesets</title>
 
 	<para>Mercurial will tell a hook what means are, or were, used
@@ -1458,7 +1458,7 @@
 	  </listitem></itemizedlist>
 
       </sect3>
-      <sect3 id="sec:hook:url">
+      <sect3 id="sec.hook.url">
 	<title>Where changes are going&emdash;remote repository
 	  URLs</title>
 
@@ -1500,7 +1500,7 @@
   <sect1>
     <title>Hook reference</title>
 
-    <sect2 id="sec:hook:changegroup">
+    <sect2 id="sec.hook.changegroup">
       <title><literal role="hook">changegroup</literal>&emdash;after
 	remote changesets added</title>
 
@@ -1535,26 +1535,26 @@
 	</listitem>
 	<listitem><para><literal>source</literal>: A string.  The
 	    source of these changes.  See section <xref
-	      linkend="sec:hook:sources"/> for details.
+	      linkend="sec.hook.sources"/> for details.
 	  </para>
 	</listitem>
 	<listitem><para><literal>url</literal>: A URL.  The location
 	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
+	      linkend="sec.hook.url"/> for more
 	    information.
 	  </para>
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">incoming</literal> (section
-	<xref linkend="sec:hook:incoming"/>), <literal
+	<xref linkend="sec.hook.incoming"/>), <literal
 	  role="hook">prechangegroup</literal> (section <xref
-	  linkend="sec:hook:prechangegroup"/>), <literal
+	  linkend="sec.hook.prechangegroup"/>), <literal
 	  role="hook">pretxnchangegroup</literal> (section <xref
-	  linkend="sec:hook:pretxnchangegroup"/>)
+	  linkend="sec.hook.pretxnchangegroup"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:commit">
+    <sect2 id="sec.hook.commit">
       <title><literal role="hook">commit</literal>&emdash;after a new
 	changeset is created</title>
 
@@ -1580,13 +1580,13 @@
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">precommit</literal>
-	(section <xref linkend="sec:hook:precommit"/>), <literal
+	(section <xref linkend="sec.hook.precommit"/>), <literal
 	  role="hook">pretxncommit</literal> (section <xref
-	  linkend="sec:hook:pretxncommit"/>)
+	  linkend="sec.hook.pretxncommit"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:incoming">
+    <sect2 id="sec.hook.incoming">
       <title><literal role="hook">incoming</literal>&emdash;after one
 	remote changeset is added</title>
 
@@ -1599,7 +1599,7 @@
 
       <para>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
+	  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>
@@ -1613,26 +1613,26 @@
 	</listitem>
 	<listitem><para><literal>source</literal>: A string.  The
 	    source of these changes.  See section <xref
-	      linkend="sec:hook:sources"/> for details.
+	      linkend="sec.hook.sources"/> for details.
 	  </para>
 	</listitem>
 	<listitem><para><literal>url</literal>: A URL.  The location
 	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
+	      linkend="sec.hook.url"/> for more
 	    information.
 	  </para>
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">changegroup</literal>
-	(section <xref linkend="sec:hook:changegroup"/>) <literal
+	(section <xref linkend="sec.hook.changegroup"/>) <literal
 	  role="hook">prechangegroup</literal> (section <xref
-	  linkend="sec:hook:prechangegroup"/>), <literal
+	  linkend="sec.hook.prechangegroup"/>), <literal
 	  role="hook">pretxnchangegroup</literal> (section <xref
-	  linkend="sec:hook:pretxnchangegroup"/>)
+	  linkend="sec.hook.pretxnchangegroup"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:outgoing">
+    <sect2 id="sec.hook.outgoing">
       <title><literal role="hook">outgoing</literal>&emdash;after
 	changesets are propagated</title>
 
@@ -1656,7 +1656,7 @@
 	</listitem>
 	<listitem><para><literal>source</literal>: A string.  The
 	    source of the of the operation (see section <xref
-	      linkend="sec:hook:sources"/>).  If a remote
+	      linkend="sec.hook.sources"/>).  If a remote
 	    client pulled changes from this repository,
 	    <literal>source</literal> will be
 	    <literal>serve</literal>.  If the client that obtained
@@ -1669,17 +1669,17 @@
 	</listitem>
 	<listitem><para><literal>url</literal>: A URL.  The location
 	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
+	      linkend="sec.hook.url"/> for more
 	    information.
 	  </para>
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">preoutgoing</literal>
-	(section <xref linkend="sec:hook:preoutgoing"/>)
+	(section <xref linkend="sec.hook.preoutgoing"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:prechangegroup">
+    <sect2 id="sec.hook.prechangegroup">
       <title><literal
 	  role="hook">prechangegroup</literal>&emdash;before starting
 	to add remote changesets</title>
@@ -1706,26 +1706,26 @@
       <itemizedlist>
 	<listitem><para><literal>source</literal>: A string.  The
 	    source of these changes.  See section <xref
-	      linkend="sec:hook:sources"/> for details.
+	      linkend="sec.hook.sources"/> for details.
 	  </para>
 	</listitem>
 	<listitem><para><literal>url</literal>: A URL.  The location
 	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
+	      linkend="sec.hook.url"/> for more
 	    information.
 	  </para>
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">changegroup</literal>
-	(section <xref linkend="sec:hook:changegroup"/>), <literal
+	(section <xref linkend="sec.hook.changegroup"/>), <literal
 	  role="hook">incoming</literal> (section <xref
-	  linkend="sec:hook:incoming"/>), , <literal
+	  linkend="sec.hook.incoming"/>), , <literal
 	  role="hook">pretxnchangegroup</literal> (section <xref
-	  linkend="sec:hook:pretxnchangegroup"/>)
+	  linkend="sec.hook.pretxnchangegroup"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:precommit">
+    <sect2 id="sec.hook.precommit">
       <title><literal role="hook">precommit</literal>&emdash;before
 	starting to commit a changeset</title>
 
@@ -1759,13 +1759,13 @@
       </para>
 
       <para>See also: <literal role="hook">commit</literal> (section
-	<xref linkend="sec:hook:commit"/>), <literal
+	<xref linkend="sec.hook.commit"/>), <literal
 	  role="hook">pretxncommit</literal> (section <xref
-	  linkend="sec:hook:pretxncommit"/>)
+	  linkend="sec.hook.pretxncommit"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:preoutgoing">
+    <sect2 id="sec.hook.preoutgoing">
       <title><literal role="hook">preoutgoing</literal>&emdash;before
 	starting to propagate changesets</title>
 
@@ -1783,27 +1783,27 @@
 	<listitem><para><literal>source</literal>: A string.  The
 	    source of the operation that is attempting to obtain
 	    changes from this repository (see section <xref
-	      linkend="sec:hook:sources"/>).  See the documentation
+	      linkend="sec.hook.sources"/>).  See the documentation
 	    for the <literal>source</literal> parameter to the
 	    <literal role="hook">outgoing</literal> hook, in section
-	    <xref linkend="sec:hook:outgoing"/>, for possible values
+	    <xref linkend="sec.hook.outgoing"/>, for possible values
 	    of
 	    this parameter.
 	  </para>
 	</listitem>
 	<listitem><para><literal>url</literal>: A URL.  The location
 	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
+	      linkend="sec.hook.url"/> for more
 	    information.
 	  </para>
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">outgoing</literal> (section
-	<xref linkend="sec:hook:outgoing"/>)
+	<xref linkend="sec.hook.outgoing"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:pretag">
+    <sect2 id="sec.hook.pretag">
       <title><literal role="hook">pretag</literal>&emdash;before
 	tagging a changeset</title>
 
@@ -1834,15 +1834,15 @@
       <para>If the tag to be created is revision-controlled, the
 	<literal role="hook">precommit</literal> and <literal
 	  role="hook">pretxncommit</literal> hooks (sections <xref
-	  linkend="sec:hook:commit"/> and <xref
-	  linkend="sec:hook:pretxncommit"/>) will also be run.
+	  linkend="sec.hook.commit"/> and <xref
+	  linkend="sec.hook.pretxncommit"/>) will also be run.
       </para>
 
       <para>See also: <literal role="hook">tag</literal> (section
-	<xref linkend="sec:hook:tag"/>)
+	<xref linkend="sec.hook.tag"/>)
       </para>
     </sect2>
-    <sect2 id="sec:hook:pretxnchangegroup">
+    <sect2 id="sec.hook.pretxnchangegroup">
       <title><literal
 	  role="hook">pretxnchangegroup</literal>&emdash;before
 	completing addition of remote changesets</title>
@@ -1889,26 +1889,26 @@
 	</listitem>
 	<listitem><para><literal>source</literal>: A string.  The
 	    source of these changes.  See section <xref
-	      linkend="sec:hook:sources"/> for details.
+	      linkend="sec.hook.sources"/> for details.
 	  </para>
 	</listitem>
 	<listitem><para><literal>url</literal>: A URL.  The location
 	    of the remote repository, if known.  See section <xref
-	      linkend="sec:hook:url"/> for more
+	      linkend="sec.hook.url"/> for more
 	    information.
 	  </para>
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">changegroup</literal>
-	(section <xref linkend="sec:hook:changegroup"/>), <literal
+	(section <xref linkend="sec.hook.changegroup"/>), <literal
 	  role="hook">incoming</literal> (section <xref
-	  linkend="sec:hook:incoming"/>), <literal
+	  linkend="sec.hook.incoming"/>), <literal
 	  role="hook">prechangegroup</literal> (section <xref
-	  linkend="sec:hook:prechangegroup"/>)
+	  linkend="sec.hook.prechangegroup"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:pretxncommit">
+    <sect2 id="sec.hook.pretxncommit">
       <title><literal role="hook">pretxncommit</literal>&emdash;before
 	completing commit of new changeset</title>
 
@@ -1951,11 +1951,11 @@
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">precommit</literal>
-	(section <xref linkend="sec:hook:precommit"/>)
+	(section <xref linkend="sec.hook.precommit"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:preupdate">
+    <sect2 id="sec.hook.preupdate">
       <title><literal role="hook">preupdate</literal>&emdash;before
 	updating or merging working directory</title>
 
@@ -1983,11 +1983,11 @@
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">update</literal> (section
-	<xref linkend="sec:hook:update"/>)
+	<xref linkend="sec.hook.update"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:tag">
+    <sect2 id="sec.hook.tag">
       <title><literal role="hook">tag</literal>&emdash;after tagging a
 	changeset</title>
 
@@ -2016,15 +2016,15 @@
 
       <para>If the created tag is revision-controlled, the <literal
 	  role="hook">commit</literal> hook (section <xref
-	  linkend="sec:hook:commit"/>) is run before this hook.
+	  linkend="sec.hook.commit"/>) is run before this hook.
       </para>
 
       <para>See also: <literal role="hook">pretag</literal> (section
-	<xref linkend="sec:hook:pretag"/>)
+	<xref linkend="sec.hook.pretag"/>)
       </para>
 
     </sect2>
-    <sect2 id="sec:hook:update">
+    <sect2 id="sec.hook.update">
       <title><literal role="hook">update</literal>&emdash;after
 	updating or merging working directory</title>
 
@@ -2054,7 +2054,7 @@
 	</listitem></itemizedlist>
 
       <para>See also: <literal role="hook">preupdate</literal>
-	(section <xref linkend="sec:hook:preupdate"/>)
+	(section <xref linkend="sec.hook.preupdate"/>)
       </para>
 
     </sect2>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch11-template.xml
--- a/en/ch11-template.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch11-template.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:template">
+<chapter id="chap.template">
   <?dbhtml filename="customizing-the-output-of-mercurial.html"?>
   <title>Customising the output of Mercurial</title>
 
@@ -10,7 +10,7 @@
     command, or to customise the entire appearance of the built-in web
     interface.</para>
 
-  <sect1 id="sec:style">
+  <sect1 id="sec.style">
     <title>Using precanned output styles</title>
 
     <para>Packaged with Mercurial are some output styles that you can
@@ -106,7 +106,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
+      section <xref linkend="sec.template.escape"/> for more details
       of escape sequences.</para>
 
     <para>A template that prints a fixed string of text all the time
@@ -124,10 +124,10 @@
       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>
+	linkend="sec.template.escape"/>.</para>
 
   </sect1>
-  <sect1 id="sec:template:keyword">
+  <sect1 id="sec.template.keyword">
     <title>Common template keywords</title>
 
     <para>You can start writing simple templates immediately using the
@@ -149,7 +149,7 @@
 	  committed.  This is <emphasis>not</emphasis> human-readable;
 	  you must pass it through a filter that will render it
 	  appropriately.  See section <xref
-	    linkend="sec:template:filter"/> for more information
+	    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
 	  1, 1970); the second is the offset of the committer's
@@ -197,12 +197,12 @@
       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>
+	linkend="sec.template.filter"/>.</para>
 
     &interaction.template.simple.datekeyword;
 
   </sect1>
-  <sect1 id="sec:template:escape">
+  <sect1 id="sec.template.escape">
     <title>Escape sequences</title>
 
     <para>Mercurial's templating engine recognises the most commonly
@@ -244,7 +244,7 @@
       it.</para>
 
   </sect1>
-  <sect1 id="sec:template:filter">
+  <sect1 id="sec.template.filter">
     <title>Filtering keywords to change their results</title>
 
     <para>Some of the results of template expansion are not
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch12-mq.xml
--- a/en/ch12-mq.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch12-mq.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,10 +1,10 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:mq">
+<chapter id="chap.mq">
   <?dbhtml filename="managing-change-with-mercurial-queues.html"?>
   <title>Managing change with Mercurial Queues</title>
 
-  <sect1 id="sec:mq:patch-mgmt">
+  <sect1 id="sec.mq.patch-mgmt">
     <title>The patch management problem</title>
 
     <para>Here is a common scenario: you need to install a software
@@ -37,7 +37,7 @@
     <para>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
-	linkend="sec:mq:patch"/> for a discussion of these
+	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
 	work,</quote> so that for example a single patch will contain
@@ -61,7 +61,7 @@
       simplifies the patch management problem.</para>
 
   </sect1>
-  <sect1 id="sec:mq:history">
+  <sect1 id="sec.mq.history">
     <title>The prehistory of Mercurial Queues</title>
 
     <para>During the late 1990s, several Linux kernel developers
@@ -76,7 +76,7 @@
       successfully using these scripts to manage hundreds (sometimes
       thousands) of patches on top of the Linux kernel.</para>
 
-    <sect2 id="sec:mq:quilt">
+    <sect2 id="sec.mq.quilt">
       <title>A patchwork quilt</title>
 
       <para>In early 2003, Andreas Gruenbacher and Martin Quinson
@@ -120,7 +120,7 @@
 	Subversion working copy.</para>
 
     </sect2>
-    <sect2 id="sec:mq:quilt-mq">
+    <sect2 id="sec.mq.quilt-mq">
       <title>From patchwork quilt to Mercurial Queues</title>
 
       <para>In mid-2005, Chris Mason took the features of quilt and
@@ -183,7 +183,7 @@
       And so on.</para>
 
   </sect1>
-  <sect1 id="sec:mq:patch">
+  <sect1 id="sec.mq.patch">
     <title>Understanding patches</title>
 
     <para>Because MQ doesn't hide its patch-oriented nature, it is
@@ -241,12 +241,12 @@
       represented by one deletion and one insertion.</para>
 
     <para>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 section <xref linkend="sec.mq.adv-patch"/>), but you
       should have
       enough information now to use MQ.</para>
 
   </sect1>
-  <sect1 id="sec:mq:start">
+  <sect1 id="sec.mq.start">
     <title>Getting started with Mercurial Queues</title>
 
     <para>Because MQ is implemented as an extension, you must
@@ -400,12 +400,12 @@
 	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
+	  linkend="fig.mq.stack"/> illustrates
 	the difference between applied and tracked patches.</para>
 
-      <informalfigure id="fig:mq:stack">
+      <informalfigure id="fig.mq.stack">
 	<mediaobject><imageobject><imagedata
-				    fileref="mq-stack"/></imageobject><textobject><phrase>XXX 
+				    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>
@@ -440,7 +440,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"/>
+	see section <xref linkend="sec.mq.perf"/>
 	below.)</para>
 
 &interaction.mq.tutorial.qpush-a;
@@ -501,7 +501,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:mq:adv-patch">
+  <sect1 id="sec.mq.adv-patch">
     <title>More about patches</title>
 
     <para>MQ uses the GNU <command>patch</command> command to apply
@@ -700,7 +700,7 @@
 	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>
+	  linkend="sec.mq.merge"/> for details.</para>
 
       <para>Unfortunately, there aren't any great techniques for
 	dealing with rejected hunks.  Most often, you'll need to view
@@ -747,7 +747,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:mq:perf">
+  <sect1 id="sec.mq.perf">
     <title>Getting the best performance out of MQ</title>
 
     <para>MQ is very efficient at handling a large number of patches.
@@ -801,7 +801,7 @@
       is zero, the second is one, and so on.</para>
 
   </sect1>
-  <sect1 id="sec:mq:merge">
+  <sect1 id="sec.mq.merge">
     <title>Updating your patches when the underlying code
       changes</title>
 
@@ -945,7 +945,7 @@
 	<programlisting>hg email qbase:qtip
 	</programlisting>
 	<para>  (Don't know what <quote>patchbombing</quote> is?  See
-	  section <xref linkend="sec:hgext:patchbomb"/>.)</para>
+	  section <xref linkend="sec.hgext.patchbomb"/>.)</para>
       </listitem>
       <listitem><para>Need to see all of the patches since
 	  <literal>foo.patch</literal> that have touched files in a
@@ -987,7 +987,7 @@
 	  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
-	    linkend="sec:mqref:cmd:qpush"/> for
+	    linkend="sec.mqref.cmd.qpush"/> for
 	  information as to why this is.</para>
       </listitem>
       <listitem><para>It's not a good idea to <command
@@ -1000,7 +1000,7 @@
       </listitem></itemizedlist>
 
   </sect1>
-  <sect1 id="sec:mq:repo">
+  <sect1 id="sec.mq.repo">
     <title>Managing patches in a repository</title>
 
     <para>Because MQ's <filename role="special"
@@ -1108,7 +1108,7 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:mq:tools">
+  <sect1 id="sec.mq.tools">
     <title>Third party tools for working with patches</title>
 
     <para>Once you've been working with patches for a while, you'll
@@ -1140,7 +1140,7 @@
       invocation of <command>filterdiff</command> can generate a
       smaller patch that only touches files whose names match a
       particular glob pattern.  See section <xref
-	linkend="mq-collab:tips:interdiff"/> for another
+	linkend="mq-collab.tips.interdiff"/> for another
       example.</para>
 
   </sect1>
@@ -1177,7 +1177,7 @@
 
     <para>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 section <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
@@ -1226,7 +1226,7 @@
       &interaction.mq.tarball.repush;
 
     </sect2>
-    <sect2 id="sec:mq:combine">
+    <sect2 id="sec.mq.combine">
       <title>Combining entire patches</title>
 
       <para>MQ provides a command, <command
@@ -1299,7 +1299,7 @@
 
       <para>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 section <xref linkend="sec.mq.combine"/>.</para>
 
     </sect2>
   </sect1>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch13-mq-collab.xml
--- a/en/ch13-mq-collab.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch13-mq-collab.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:mq-collab">
+<chapter id="chap.mq-collab">
   <?dbhtml filename="advanced-uses-of-mercurial-queues.html"?>
   <title>Advanced uses of Mercurial Queues</title>
 
@@ -430,12 +430,12 @@
 	path separators.</para>
 
     </sect2>
-    <sect2 id="mq-collab:tips:interdiff">
+    <sect2 id="mq-collab.tips.interdiff">
       <title>Viewing the history of a patch</title>
 
       <para>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 section <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
@@ -506,7 +506,7 @@
       <para>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
-	  linkend="sec:hgext:extdiff"/>.</para>
+	  linkend="sec.hgext.extdiff"/>.</para>
 
     </sect2>
   </sect1>
diff -r 3c5e1c03cc3e -r cfdb601a3c8b en/ch14-hgext.xml
--- a/en/ch14-hgext.xml	Thu Mar 12 15:47:15 2009 +0800
+++ b/en/ch14-hgext.xml	Thu Mar 12 15:51:39 2009 +0800
@@ -1,6 +1,6 @@
 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
 
-<chapter id="chap:hgext">
+<chapter id="chap.hgext">
   <?dbhtml filename="adding-functionality-with-extensions.html"?>
   <title>Adding functionality with extensions</title>
 
@@ -15,13 +15,13 @@
     <emphasis>plugins</emphasis>).  We've already discussed a few of
     these extensions in earlier chapters.</para>
   <itemizedlist>
-    <listitem><para>Section <xref linkend="sec:tour-merge:fetch"/>
+    <listitem><para>Section <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>In chapter <xref linkend="chap:hook"/>, we covered
+    <listitem><para>In chapter <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>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
+	to itself. Chapter <xref linkend="chap.mq"/> covers the
 	basics; chapter <xref
-	  linkend="chap:mq-collab"/> discusses advanced topics;
-	and appendix <xref linkend="chap:mqref"/> goes into detail on
+	  linkend="chap.mq-collab"/> discusses advanced topics;
+	and appendix <xref linkend="chap.mqref"/> goes into detail on
 	each
 	command.</para>
     </listitem></itemizedlist>
@@ -45,13 +45,13 @@
     machinery you'll need to know about if you want to write an
     extension of your own.</para>
   <itemizedlist>
-    <listitem><para>In section <xref linkend="sec:hgext:inotify"/>,
+    <listitem><para>In section <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>
     </listitem></itemizedlist>
 
-  <sect1 id="sec:hgext:inotify">
+  <sect1 id="sec.hgext.inotify">
     <title>Improve performance with the <literal
 	role="hg-ext">inotify</literal> extension</title>
 
@@ -188,7 +188,7 @@
       <listitem><para>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
-	    linkend="sec:mq:start"/> to get started
+	    linkend="sec.mq.start"/> to get started
 	  quickly.</para>
       </listitem>
       <listitem><para>Go into the <filename
@@ -263,7 +263,7 @@
       these situations occurs, please report a bug.</para>
 
   </sect1>
-  <sect1 id="sec:hgext:extdiff">
+  <sect1 id="sec.hgext.extdiff">
     <title>Flexible diff support with the <literal
 	role="hg-ext">extdiff</literal> extension</title>
 
@@ -360,7 +360,7 @@
       example of such scripting in action with the <literal
 	role="hg-ext">mq</literal> extension and the
       <command>interdiff</command> command, see section <xref
-	linkend="mq-collab:tips:interdiff"/>.</para>
+	linkend="mq-collab.tips.interdiff"/>.</para>
 
     <sect2>
       <title>Defining command aliases</title>
@@ -402,14 +402,14 @@
 
     </sect2>
   </sect1>
-  <sect1 id="sec:hgext:transplant">
+  <sect1 id="sec.hgext.transplant">
     <title>Cherrypicking changes with the <literal
 	role="hg-ext">transplant</literal> extension</title>
 
     <para>Need to have a long chat with Brendan about this.</para>
 
   </sect1>
-  <sect1 id="sec:hgext:patchbomb">
+  <sect1 id="sec.hgext.patchbomb">
     <title>Send changes via email with the <literal
 	role="hg-ext">patchbomb</literal> extension</title>
 
@@ -504,7 +504,7 @@
 	    use.</para>
 	</listitem>
 	<listitem><para>The default behaviour is to send unified diffs
-	    (see section <xref linkend="sec:mq:patch"/> for a
+	    (see section <xref linkend="sec.mq.patch"/> for a
 	    description of the
 	    format), one per message.  You can send a binary bundle
 	    instead with the <option