1.1 --- a/en/ch04-concepts.xml	Mon Mar 09 23:37:29 2009 -0700
     1.2 +++ b/en/ch04-concepts.xml	Mon Mar 16 17:49:05 2009 +0800
     1.3 @@ -1,6 +1,6 @@
     1.4  <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     1.5  
     1.6 -<chapter id="chap:concepts">
     1.7 +<chapter id="chap.concepts">
     1.8    <?dbhtml filename="behind-the-scenes.html"?>
     1.9    <title>Behind the scenes</title>
    1.10  
    1.11 @@ -47,11 +47,11 @@
    1.12  	file.  The correspondence between a file in the working
    1.13  	directory and the filelog that tracks its history in the
    1.14  	repository is illustrated in figure <xref
    1.15 -	  linkend="fig:concepts:filelog"/>.</para>
    1.16 -
    1.17 -      <informalfigure id="fig:concepts:filelog">
    1.18 +	  linkend="fig.concepts.filelog"/>.</para>
    1.19 +
    1.20 +      <informalfigure id="fig.concepts.filelog">
    1.21  	<mediaobject><imageobject><imagedata
    1.22 -				    fileref="filelog"/></imageobject><textobject><phrase>XXX 
    1.23 +				    fileref="images/filelog.png"/></imageobject><textobject><phrase>XXX 
    1.24  	      add text</phrase></textobject>
    1.25  	  <caption><para>Relationships between files in working
    1.26  	      directory and filelogs in
    1.27 @@ -97,11 +97,11 @@
    1.28  	manifest.  A revision of the manifest stores a pointer to a
    1.29  	single revision of each filelog tracked when that changeset
    1.30  	was created.  These relationships are illustrated in figure
    1.31 -	<xref linkend="fig:concepts:metadata"/>.</para>
    1.32 -
    1.33 -      <informalfigure id="fig:concepts:metadata">
    1.34 +	<xref linkend="fig.concepts.metadata"/>.</para>
    1.35 +
    1.36 +      <informalfigure id="fig.concepts.metadata">
    1.37  	<mediaobject><imageobject><imagedata
    1.38 -				    fileref="metadata"/></imageobject><textobject><phrase>XXX 
    1.39 +				    fileref="images/metadata.png"/></imageobject><textobject><phrase>XXX 
    1.40  	      add text</phrase></textobject><caption><para>Metadata
    1.41  	      relationships</para></caption>
    1.42  	</mediaobject>
    1.43 @@ -145,7 +145,7 @@
    1.44  	doesn't need to treat text as special.</para>
    1.45  
    1.46      </sect2>
    1.47 -    <sect2 id="sec:concepts:txn">
    1.48 +    <sect2 id="sec.concepts.txn">
    1.49        <title>Safe operation</title>
    1.50  
    1.51        <para>Mercurial only ever <emphasis>appends</emphasis> data to
    1.52 @@ -184,9 +184,9 @@
    1.53  	file accumulates, the more revisions you must read, hence the
    1.54  	longer it takes to reconstruct a particular revision.</para>
    1.55  
    1.56 -      <informalfigure id="fig:concepts:snapshot">
    1.57 +      <informalfigure id="fig.concepts.snapshot">
    1.58  	<mediaobject><imageobject><imagedata
    1.59 -				    fileref="snapshot"/></imageobject><textobject><phrase>XXX 
    1.60 +				    fileref="images/snapshot.png"/></imageobject><textobject><phrase>XXX 
    1.61  	      add text</phrase></textobject><caption><para>Snapshot of
    1.62  	      a revlog, with incremental
    1.63  	      deltas</para></caption></mediaobject>
    1.64 @@ -201,7 +201,7 @@
    1.65  	quickly.  This approach works so well that it has since been
    1.66  	copied by several other revision control systems.</para>
    1.67  
    1.68 -      <para>Figure <xref linkend="fig:concepts:snapshot"/> illustrates
    1.69 +      <para>Figure <xref linkend="fig.concepts.snapshot"/> illustrates
    1.70  	the idea.  In an entry in a revlog's index file, Mercurial
    1.71  	stores the range of entries from the data file that it must
    1.72  	read to reconstruct a particular revision.</para>
    1.73 @@ -273,7 +273,7 @@
    1.74        <quote>there is no parent here</quote>.  This hash is simply a
    1.75        string of zeroes.</para>
    1.76  
    1.77 -    <para>In figure <xref linkend="fig:concepts:revlog"/>, you can see
    1.78 +    <para>In figure <xref linkend="fig.concepts.revlog"/>, you can see
    1.79        an example of the conceptual structure of a revlog.  Filelogs,
    1.80        manifests, and changelogs all have this same structure; they
    1.81        differ only in the kind of data stored in each delta or
    1.82 @@ -288,9 +288,9 @@
    1.83        revision that represents a merge between branches has two normal
    1.84        revision IDs in its parent slots.</para>
    1.85  
    1.86 -    <informalfigure id="fig:concepts:revlog">
    1.87 +    <informalfigure id="fig.concepts.revlog">
    1.88        <mediaobject><imageobject><imagedata
    1.89 -				  fileref="revlog"/></imageobject><textobject><phrase>XXX 
    1.90 +				  fileref="images/revlog.png"/></imageobject><textobject><phrase>XXX 
    1.91  	    add text</phrase></textobject></mediaobject>
    1.92      </informalfigure>
    1.93  
    1.94 @@ -337,23 +337,23 @@
    1.95  	dirstate as <emphasis>the parents of a new
    1.96  	  changeset</emphasis> when you perform a commit.</para>
    1.97  
    1.98 -      <informalfigure id="fig:concepts:wdir">
    1.99 +      <informalfigure id="fig.concepts.wdir">
   1.100  	<mediaobject><imageobject><imagedata
   1.101 -				    fileref="wdir"/></imageobject><textobject><phrase>XXX 
   1.102 +				    fileref="images/wdir.png"/></imageobject><textobject><phrase>XXX 
   1.103  	      add text</phrase></textobject><caption><para>The working
   1.104  	      directory can have two
   1.105  	      parents</para></caption></mediaobject>
   1.106        </informalfigure>
   1.107  
   1.108 -      <para>Figure <xref linkend="fig:concepts:wdir"/> shows the
   1.109 +      <para>Figure <xref linkend="fig.concepts.wdir"/> shows the
   1.110  	normal state of the working directory, where it has a single
   1.111  	changeset as parent.  That changeset is the
   1.112  	<emphasis>tip</emphasis>, the newest changeset in the
   1.113  	repository that has no children.</para>
   1.114  
   1.115 -      <informalfigure id="fig:concepts:wdir-after-commit">
   1.116 +      <informalfigure id="fig.concepts.wdir-after-commit">
   1.117  	<mediaobject><imageobject><imagedata
   1.118 -				    fileref="wdir-after-commit"/></imageobject><textobject><phrase>XXX 
   1.119 +				    fileref="images/wdir-after-commit.png"/></imageobject><textobject><phrase>XXX 
   1.120  	      add text</phrase></textobject><caption><para>The working
   1.121  	      directory gains new parents after a
   1.122  	      commit</para></caption></mediaobject>
   1.123 @@ -370,7 +370,7 @@
   1.124        <para>After a commit, Mercurial will update the parents of the
   1.125  	working directory, so that the first parent is the ID of the
   1.126  	new changeset, and the second is the null ID.  This is shown
   1.127 -	in figure <xref linkend="fig:concepts:wdir-after-commit"/>.
   1.128 +	in figure <xref linkend="fig.concepts.wdir-after-commit"/>.
   1.129  	Mercurial
   1.130  	doesn't touch any of the files in the working directory when
   1.131  	you commit; it just modifies the dirstate to note its new
   1.132 @@ -389,11 +389,11 @@
   1.133  	interested in, and then examine the files in the working
   1.134  	directory directly to see their contents as they were when you
   1.135  	committed that changeset.  The effect of this is shown in
   1.136 -	figure <xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
   1.137 -
   1.138 -      <informalfigure id="fig:concepts:wdir-pre-branch">
   1.139 +	figure <xref linkend="fig.concepts.wdir-pre-branch"/>.</para>
   1.140 +
   1.141 +      <informalfigure id="fig.concepts.wdir-pre-branch">
   1.142  	<mediaobject><imageobject><imagedata
   1.143 -				    fileref="wdir-pre-branch"/></imageobject><textobject><phrase>XXX 
   1.144 +				    fileref="images/wdir-pre-branch.png"/></imageobject><textobject><phrase>XXX 
   1.145  	      add text</phrase></textobject><caption><para>The working
   1.146  	      directory, updated to an older
   1.147  	      changeset</para></caption></mediaobject>
   1.148 @@ -408,11 +408,11 @@
   1.149  	contains two changesets that have no children; we call these
   1.150  	<emphasis>heads</emphasis>.  You can see the structure that
   1.151  	this creates in figure <xref
   1.152 -	  linkend="fig:concepts:wdir-branch"/>.</para>
   1.153 -
   1.154 -      <informalfigure id="fig:concepts:wdir-branch">
   1.155 +	  linkend="fig.concepts.wdir-branch"/>.</para>
   1.156 +
   1.157 +      <informalfigure id="fig.concepts.wdir-branch">
   1.158  	<mediaobject><imageobject><imagedata
   1.159 -				    fileref="wdir-branch"/></imageobject><textobject><phrase>XXX 
   1.160 +				    fileref="images/wdir-branch.png"/></imageobject><textobject><phrase>XXX 
   1.161  	      add text</phrase></textobject><caption><para>After a
   1.162  	      commit made while synced to an older
   1.163  	      changeset</para></caption></mediaobject>
   1.164 @@ -449,11 +449,11 @@
   1.165  	command, Mercurial leaves the first parent of the working
   1.166  	directory unchanged, and sets the second parent to the
   1.167  	changeset you're merging with, as shown in figure <xref
   1.168 -	  linkend="fig:concepts:wdir-merge"/>.</para>
   1.169 -
   1.170 -      <informalfigure id="fig:concepts:wdir-merge">
   1.171 +	  linkend="fig.concepts.wdir-merge"/>.</para>
   1.172 +
   1.173 +      <informalfigure id="fig.concepts.wdir-merge">
   1.174  	<mediaobject><imageobject><imagedata
   1.175 -				    fileref="wdir-merge"/></imageobject><textobject><phrase>XXX 
   1.176 +				    fileref="images/wdir-merge.png"/></imageobject><textobject><phrase>XXX 
   1.177  	      add text</phrase></textobject><caption><para>Merging two
   1.178  	      heads</para></caption></mediaobject>
   1.179        </informalfigure>
   1.180 @@ -582,7 +582,7 @@
   1.181  
   1.182        <para>Appending to files isn't the whole story when it comes to
   1.183  	guaranteeing that a reader won't see a partial write.  If you
   1.184 -	recall figure <xref linkend="fig:concepts:metadata"/>,
   1.185 +	recall figure <xref linkend="fig.concepts.metadata"/>,
   1.186  	revisions in the
   1.187  	changelog point to revisions in the manifest, and revisions in
   1.188  	the manifest point to revisions in filelogs.  This hierarchy