1.1 --- a/en/ch03-concepts.xml	Thu Mar 19 20:54:12 2009 -0700
     1.2 +++ b/en/ch03-concepts.xml	Thu Mar 19 22:42:14 2009 -0700
     1.3 @@ -4,20 +4,20 @@
     1.4    <?dbhtml filename="behind-the-scenes.html"?>
     1.5    <title>Behind the scenes</title>
     1.6  
     1.7 -  <para>Unlike many revision control systems, the concepts upon which
     1.8 +  <para id="x_2e8">Unlike many revision control systems, the concepts upon which
     1.9      Mercurial is built are simple enough that it's easy to understand
    1.10      how the software really works.  Knowing this certainly isn't
    1.11      necessary, but I find it useful to have a <quote>mental
    1.12        model</quote> of what's going on.</para>
    1.13  
    1.14 -  <para>This understanding gives me confidence that Mercurial has been
    1.15 +  <para id="x_2e9">This understanding gives me confidence that Mercurial has been
    1.16      carefully designed to be both <emphasis>safe</emphasis> and
    1.17      <emphasis>efficient</emphasis>.  And just as importantly, if it's
    1.18      easy for me to retain a good idea of what the software is doing
    1.19      when I perform a revision control task, I'm less likely to be
    1.20      surprised by its behaviour.</para>
    1.21  
    1.22 -  <para>In this chapter, we'll initially cover the core concepts
    1.23 +  <para id="x_2ea">In this chapter, we'll initially cover the core concepts
    1.24      behind Mercurial's design, then continue to discuss some of the
    1.25      interesting details of its implementation.</para>
    1.26  
    1.27 @@ -27,7 +27,7 @@
    1.28      <sect2>
    1.29        <title>Tracking the history of a single file</title>
    1.30  
    1.31 -      <para>When Mercurial tracks modifications to a file, it stores
    1.32 +      <para id="x_2eb">When Mercurial tracks modifications to a file, it stores
    1.33  	the history of that file in a metadata object called a
    1.34  	<emphasis>filelog</emphasis>.  Each entry in the filelog
    1.35  	contains enough information to reconstruct one revision of the
    1.36 @@ -38,7 +38,7 @@
    1.37  	an index to help Mercurial to find a revision
    1.38  	efficiently.</para>
    1.39  
    1.40 -      <para>A file that is large, or has a lot of history, has its
    1.41 +      <para id="x_2ec">A file that is large, or has a lot of history, has its
    1.42  	filelog stored in separate data
    1.43  	(<quote><literal>.d</literal></quote> suffix) and index
    1.44  	(<quote><literal>.i</literal></quote> suffix) files.  For
    1.45 @@ -53,7 +53,7 @@
    1.46  	<mediaobject><imageobject><imagedata
    1.47  				    fileref="filelog"/></imageobject><textobject><phrase>XXX 
    1.48  	      add text</phrase></textobject>
    1.49 -	  <caption><para>Relationships between files in working
    1.50 +	  <caption><para id="x_2ed">Relationships between files in working
    1.51  	      directory and filelogs in
    1.52  	      repository</para></caption></mediaobject>
    1.53        </informalfigure>
    1.54 @@ -62,7 +62,7 @@
    1.55      <sect2>
    1.56        <title>Managing tracked files</title>
    1.57  
    1.58 -      <para>Mercurial uses a structure called a
    1.59 +      <para id="x_2ee">Mercurial uses a structure called a
    1.60  	<emphasis>manifest</emphasis> to collect together information
    1.61  	about the files that it tracks.  Each entry in the manifest
    1.62  	contains information about the files present in a single
    1.63 @@ -74,7 +74,7 @@
    1.64      <sect2>
    1.65        <title>Recording changeset information</title>
    1.66  
    1.67 -      <para>The <emphasis>changelog</emphasis> contains information
    1.68 +      <para id="x_2ef">The <emphasis>changelog</emphasis> contains information
    1.69  	about each changeset.  Each revision records who committed a
    1.70  	change, the changeset comment, other pieces of
    1.71  	changeset-related information, and the revision of the
    1.72 @@ -84,14 +84,14 @@
    1.73      <sect2>
    1.74        <title>Relationships between revisions</title>
    1.75  
    1.76 -      <para>Within a changelog, a manifest, or a filelog, each
    1.77 +      <para id="x_2f0">Within a changelog, a manifest, or a filelog, each
    1.78  	revision stores a pointer to its immediate parent (or to its
    1.79  	two parents, if it's a merge revision).  As I mentioned above,
    1.80  	there are also relationships between revisions
    1.81  	<emphasis>across</emphasis> these structures, and they are
    1.82  	hierarchical in nature.</para>
    1.83  
    1.84 -      <para>For every changeset in a repository, there is exactly one
    1.85 +      <para id="x_2f1">For every changeset in a repository, there is exactly one
    1.86  	revision stored in the changelog.  Each revision of the
    1.87  	changelog contains a pointer to a single revision of the
    1.88  	manifest.  A revision of the manifest stores a pointer to a
    1.89 @@ -102,12 +102,12 @@
    1.90        <informalfigure id="fig:concepts:metadata">
    1.91  	<mediaobject><imageobject><imagedata
    1.92  				    fileref="metadata"/></imageobject><textobject><phrase>XXX 
    1.93 -	      add text</phrase></textobject><caption><para>Metadata
    1.94 +	      add text</phrase></textobject><caption><para id="x_2f2">Metadata
    1.95  	      relationships</para></caption>
    1.96  	</mediaobject>
    1.97        </informalfigure>
    1.98  
    1.99 -      <para>As the illustration shows, there is
   1.100 +      <para id="x_2f3">As the illustration shows, there is
   1.101  	<emphasis>not</emphasis> a <quote>one to one</quote>
   1.102  	relationship between revisions in the changelog, manifest, or
   1.103  	filelog. If the manifest hasn't changed between two
   1.104 @@ -122,14 +122,14 @@
   1.105    <sect1>
   1.106      <title>Safe, efficient storage</title>
   1.107  
   1.108 -    <para>The underpinnings of changelogs, manifests, and filelogs are
   1.109 +    <para id="x_2f4">The underpinnings of changelogs, manifests, and filelogs are
   1.110        provided by a single structure called the
   1.111        <emphasis>revlog</emphasis>.</para>
   1.112  
   1.113      <sect2>
   1.114        <title>Efficient storage</title>
   1.115  
   1.116 -      <para>The revlog provides efficient storage of revisions using a
   1.117 +      <para id="x_2f5">The revlog provides efficient storage of revisions using a
   1.118  	<emphasis>delta</emphasis> mechanism.  Instead of storing a
   1.119  	complete copy of a file for each revision, it stores the
   1.120  	changes needed to transform an older revision into the new
   1.121 @@ -137,7 +137,7 @@
   1.122  	typically a fraction of a percent of the size of a full copy
   1.123  	of a file.</para>
   1.124  
   1.125 -      <para>Some obsolete revision control systems can only work with
   1.126 +      <para id="x_2f6">Some obsolete revision control systems can only work with
   1.127  	deltas of text files.  They must either store binary files as
   1.128  	complete snapshots or encoded into a text representation, both
   1.129  	of which are wasteful approaches.  Mercurial can efficiently
   1.130 @@ -148,13 +148,13 @@
   1.131      <sect2 id="sec:concepts:txn">
   1.132        <title>Safe operation</title>
   1.133  
   1.134 -      <para>Mercurial only ever <emphasis>appends</emphasis> data to
   1.135 +      <para id="x_2f7">Mercurial only ever <emphasis>appends</emphasis> data to
   1.136  	the end of a revlog file. It never modifies a section of a
   1.137  	file after it has written it.  This is both more robust and
   1.138  	efficient than schemes that need to modify or rewrite
   1.139  	data.</para>
   1.140  
   1.141 -      <para>In addition, Mercurial treats every write as part of a
   1.142 +      <para id="x_2f8">In addition, Mercurial treats every write as part of a
   1.143  	<emphasis>transaction</emphasis> that can span a number of
   1.144  	files.  A transaction is <emphasis>atomic</emphasis>: either
   1.145  	the entire transaction succeeds and its effects are all
   1.146 @@ -164,7 +164,7 @@
   1.147  	writing it, the reader will never see a partially written
   1.148  	result that might confuse it.</para>
   1.149  
   1.150 -      <para>The fact that Mercurial only appends to files makes it
   1.151 +      <para id="x_2f9">The fact that Mercurial only appends to files makes it
   1.152  	easier to provide this transactional guarantee.  The easier it
   1.153  	is to do stuff like this, the more confident you should be
   1.154  	that it's done correctly.</para>
   1.155 @@ -173,7 +173,7 @@
   1.156      <sect2>
   1.157        <title>Fast retrieval</title>
   1.158  
   1.159 -      <para>Mercurial cleverly avoids a pitfall common to all earlier
   1.160 +      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to all earlier
   1.161  	revision control systems: the problem of <emphasis>inefficient
   1.162  	  retrieval</emphasis>. Most revision control systems store
   1.163  	the contents of a revision as an incremental series of
   1.164 @@ -187,12 +187,12 @@
   1.165        <informalfigure id="fig:concepts:snapshot">
   1.166  	<mediaobject><imageobject><imagedata
   1.167  				    fileref="snapshot"/></imageobject><textobject><phrase>XXX 
   1.168 -	      add text</phrase></textobject><caption><para>Snapshot of
   1.169 +	      add text</phrase></textobject><caption><para id="x_2fb">Snapshot of
   1.170  	      a revlog, with incremental
   1.171  	      deltas</para></caption></mediaobject>
   1.172        </informalfigure>
   1.173  
   1.174 -      <para>The innovation that Mercurial applies to this problem is
   1.175 +      <para id="x_2fc">The innovation that Mercurial applies to this problem is
   1.176  	simple but effective.  Once the cumulative amount of delta
   1.177  	information stored since the last snapshot exceeds a fixed
   1.178  	threshold, it stores a new snapshot (compressed, of course),
   1.179 @@ -201,7 +201,7 @@
   1.180  	quickly.  This approach works so well that it has since been
   1.181  	copied by several other revision control systems.</para>
   1.182  
   1.183 -      <para>Figure <xref linkend="fig:concepts:snapshot"/> illustrates
   1.184 +      <para id="x_2fd">Figure <xref linkend="fig:concepts:snapshot"/> illustrates
   1.185  	the idea.  In an entry in a revlog's index file, Mercurial
   1.186  	stores the range of entries from the data file that it must
   1.187  	read to reconstruct a particular revision.</para>
   1.188 @@ -209,7 +209,7 @@
   1.189        <sect3>
   1.190  	<title>Aside: the influence of video compression</title>
   1.191  
   1.192 -	<para>If you're familiar with video compression or have ever
   1.193 +	<para id="x_2fe">If you're familiar with video compression or have ever
   1.194  	  watched a TV feed through a digital cable or satellite
   1.195  	  service, you may know that most video compression schemes
   1.196  	  store each frame of video as a delta against its predecessor
   1.197 @@ -218,7 +218,7 @@
   1.198  	  visual errors accumulate over the course of a number of
   1.199  	  inter-frame deltas.</para>
   1.200  
   1.201 -	<para>Because it's possible for a video stream to <quote>drop
   1.202 +	<para id="x_2ff">Because it's possible for a video stream to <quote>drop
   1.203  	    out</quote> occasionally due to signal glitches, and to
   1.204  	  limit the accumulation of artefacts introduced by the lossy
   1.205  	  compression process, video encoders periodically insert a
   1.206 @@ -234,24 +234,24 @@
   1.207      <sect2>
   1.208        <title>Identification and strong integrity</title>
   1.209  
   1.210 -      <para>Along with delta or snapshot information, a revlog entry
   1.211 +      <para id="x_300">Along with delta or snapshot information, a revlog entry
   1.212  	contains a cryptographic hash of the data that it represents.
   1.213  	This makes it difficult to forge the contents of a revision,
   1.214  	and easy to detect accidental corruption.</para>
   1.215  
   1.216 -      <para>Hashes provide more than a mere check against corruption;
   1.217 +      <para id="x_301">Hashes provide more than a mere check against corruption;
   1.218  	they are used as the identifiers for revisions.  The changeset
   1.219  	identification hashes that you see as an end user are from
   1.220  	revisions of the changelog.  Although filelogs and the
   1.221  	manifest also use hashes, Mercurial only uses these behind the
   1.222  	scenes.</para>
   1.223  
   1.224 -      <para>Mercurial verifies that hashes are correct when it
   1.225 +      <para id="x_302">Mercurial verifies that hashes are correct when it
   1.226  	retrieves file revisions and when it pulls changes from
   1.227  	another repository.  If it encounters an integrity problem, it
   1.228  	will complain and stop whatever it's doing.</para>
   1.229  
   1.230 -      <para>In addition to the effect it has on retrieval efficiency,
   1.231 +      <para id="x_303">In addition to the effect it has on retrieval efficiency,
   1.232  	Mercurial's use of periodic snapshots makes it more robust
   1.233  	against partial data corruption.  If a revlog becomes partly
   1.234  	corrupted due to a hardware error or system bug, it's often
   1.235 @@ -265,7 +265,7 @@
   1.236    <sect1>
   1.237      <title>Revision history, branching, and merging</title>
   1.238  
   1.239 -    <para>Every entry in a Mercurial revlog knows the identity of its
   1.240 +    <para id="x_304">Every entry in a Mercurial revlog knows the identity of its
   1.241        immediate ancestor revision, usually referred to as its
   1.242        <emphasis>parent</emphasis>.  In fact, a revision contains room
   1.243        for not one parent, but two.  Mercurial uses a special hash,
   1.244 @@ -273,13 +273,13 @@
   1.245        <quote>there is no parent here</quote>.  This hash is simply a
   1.246        string of zeroes.</para>
   1.247  
   1.248 -    <para>In figure <xref linkend="fig:concepts:revlog"/>, you can see
   1.249 +    <para id="x_305">In figure <xref linkend="fig:concepts:revlog"/>, you can see
   1.250        an example of the conceptual structure of a revlog.  Filelogs,
   1.251        manifests, and changelogs all have this same structure; they
   1.252        differ only in the kind of data stored in each delta or
   1.253        snapshot.</para>
   1.254  
   1.255 -    <para>The first revision in a revlog (at the bottom of the image)
   1.256 +    <para id="x_306">The first revision in a revlog (at the bottom of the image)
   1.257        has the null ID in both of its parent slots.  For a
   1.258        <quote>normal</quote> revision, its first parent slot contains
   1.259        the ID of its parent revision, and its second contains the null
   1.260 @@ -298,10 +298,10 @@
   1.261    <sect1>
   1.262      <title>The working directory</title>
   1.263  
   1.264 -    <para>In the working directory, Mercurial stores a snapshot of the
   1.265 +    <para id="x_307">In the working directory, Mercurial stores a snapshot of the
   1.266        files from the repository as of a particular changeset.</para>
   1.267  
   1.268 -    <para>The working directory <quote>knows</quote> which changeset
   1.269 +    <para id="x_308">The working directory <quote>knows</quote> which changeset
   1.270        it contains.  When you update the working directory to contain a
   1.271        particular changeset, Mercurial looks up the appropriate
   1.272        revision of the manifest to find out which files it was tracking
   1.273 @@ -310,13 +310,13 @@
   1.274        those files, with the same contents it had when the changeset
   1.275        was committed.</para>
   1.276  
   1.277 -    <para>The <emphasis>dirstate</emphasis> contains Mercurial's
   1.278 +    <para id="x_309">The <emphasis>dirstate</emphasis> contains Mercurial's
   1.279        knowledge of the working directory.  This details which
   1.280        changeset the working directory is updated to, and all of the
   1.281        files that Mercurial is tracking in the working
   1.282        directory.</para>
   1.283  
   1.284 -    <para>Just as a revision of a revlog has room for two parents, so
   1.285 +    <para id="x_30a">Just as a revision of a revlog has room for two parents, so
   1.286        that it can represent either a normal revision (with one parent)
   1.287        or a merge of two earlier revisions, the dirstate has slots for
   1.288        two parents.  When you use the <command role="hg-cmd">hg
   1.289 @@ -332,7 +332,7 @@
   1.290      <sect2>
   1.291        <title>What happens when you commit</title>
   1.292  
   1.293 -      <para>The dirstate stores parent information for more than just
   1.294 +      <para id="x_30b">The dirstate stores parent information for more than just
   1.295  	book-keeping purposes.  Mercurial uses the parents of the
   1.296  	dirstate as <emphasis>the parents of a new
   1.297  	  changeset</emphasis> when you perform a commit.</para>
   1.298 @@ -340,12 +340,12 @@
   1.299        <informalfigure id="fig:concepts:wdir">
   1.300  	<mediaobject><imageobject><imagedata
   1.301  				    fileref="wdir"/></imageobject><textobject><phrase>XXX 
   1.302 -	      add text</phrase></textobject><caption><para>The working
   1.303 +	      add text</phrase></textobject><caption><para id="x_30c">The working
   1.304  	      directory can have two
   1.305  	      parents</para></caption></mediaobject>
   1.306        </informalfigure>
   1.307  
   1.308 -      <para>Figure <xref linkend="fig:concepts:wdir"/> shows the
   1.309 +      <para id="x_30d">Figure <xref linkend="fig:concepts:wdir"/> shows the
   1.310  	normal state of the working directory, where it has a single
   1.311  	changeset as parent.  That changeset is the
   1.312  	<emphasis>tip</emphasis>, the newest changeset in the
   1.313 @@ -354,12 +354,12 @@
   1.314        <informalfigure id="fig:concepts:wdir-after-commit">
   1.315  	<mediaobject><imageobject><imagedata
   1.316  				    fileref="wdir-after-commit"/></imageobject><textobject><phrase>XXX 
   1.317 -	      add text</phrase></textobject><caption><para>The working
   1.318 +	      add text</phrase></textobject><caption><para id="x_30e">The working
   1.319  	      directory gains new parents after a
   1.320  	      commit</para></caption></mediaobject>
   1.321        </informalfigure>
   1.322  
   1.323 -      <para>It's useful to think of the working directory as
   1.324 +      <para id="x_30f">It's useful to think of the working directory as
   1.325  	<quote>the changeset I'm about to commit</quote>.  Any files
   1.326  	that you tell Mercurial that you've added, removed, renamed,
   1.327  	or copied will be reflected in that changeset, as will
   1.328 @@ -367,7 +367,7 @@
   1.329  	the new changeset will have the parents of the working
   1.330  	directory as its parents.</para>
   1.331  
   1.332 -      <para>After a commit, Mercurial will update the parents of the
   1.333 +      <para id="x_310">After a commit, Mercurial will update the parents of the
   1.334  	working directory, so that the first parent is the ID of the
   1.335  	new changeset, and the second is the null ID.  This is shown
   1.336  	in figure <xref linkend="fig:concepts:wdir-after-commit"/>.
   1.337 @@ -380,7 +380,7 @@
   1.338      <sect2>
   1.339        <title>Creating a new head</title>
   1.340  
   1.341 -      <para>It's perfectly normal to update the working directory to a
   1.342 +      <para id="x_311">It's perfectly normal to update the working directory to a
   1.343  	changeset other than the current tip.  For example, you might
   1.344  	want to know what your project looked like last Tuesday, or
   1.345  	you could be looking through changesets to see which one
   1.346 @@ -394,12 +394,12 @@
   1.347        <informalfigure id="fig:concepts:wdir-pre-branch">
   1.348  	<mediaobject><imageobject><imagedata
   1.349  				    fileref="wdir-pre-branch"/></imageobject><textobject><phrase>XXX 
   1.350 -	      add text</phrase></textobject><caption><para>The working
   1.351 +	      add text</phrase></textobject><caption><para id="x_312">The working
   1.352  	      directory, updated to an older
   1.353  	      changeset</para></caption></mediaobject>
   1.354        </informalfigure>
   1.355  
   1.356 -      <para>Having updated the working directory to an older
   1.357 +      <para id="x_313">Having updated the working directory to an older
   1.358  	changeset, what happens if you make some changes, and then
   1.359  	commit?  Mercurial behaves in the same way as I outlined
   1.360  	above.  The parents of the working directory become the
   1.361 @@ -413,13 +413,13 @@
   1.362        <informalfigure id="fig:concepts:wdir-branch">
   1.363  	<mediaobject><imageobject><imagedata
   1.364  				    fileref="wdir-branch"/></imageobject><textobject><phrase>XXX 
   1.365 -	      add text</phrase></textobject><caption><para>After a
   1.366 +	      add text</phrase></textobject><caption><para id="x_314">After a
   1.367  	      commit made while synced to an older
   1.368  	      changeset</para></caption></mediaobject>
   1.369        </informalfigure>
   1.370  
   1.371        <note>
   1.372 -	<para>  If you're new to Mercurial, you should keep in mind a
   1.373 +	<para id="x_315">  If you're new to Mercurial, you should keep in mind a
   1.374  	  common <quote>error</quote>, which is to use the <command
   1.375  	    role="hg-cmd">hg pull</command> command without any
   1.376  	  options.  By default, the <command role="hg-cmd">hg
   1.377 @@ -431,7 +431,7 @@
   1.378  	  a new head, because your working directory isn't synced to
   1.379  	  whatever the current tip is.</para>
   1.380  
   1.381 -	<para>  I put the word <quote>error</quote> in quotes because
   1.382 +	<para id="x_316">  I put the word <quote>error</quote> in quotes because
   1.383  	  all that you need to do to rectify this situation is
   1.384  	  <command role="hg-cmd">hg merge</command>, then <command
   1.385  	    role="hg-cmd">hg commit</command>.  In other words, this
   1.386 @@ -445,7 +445,7 @@
   1.387      <sect2>
   1.388        <title>Merging heads</title>
   1.389  
   1.390 -      <para>When you run the <command role="hg-cmd">hg merge</command>
   1.391 +      <para id="x_317">When you run the <command role="hg-cmd">hg merge</command>
   1.392  	command, Mercurial leaves the first parent of the working
   1.393  	directory unchanged, and sets the second parent to the
   1.394  	changeset you're merging with, as shown in figure <xref
   1.395 @@ -454,54 +454,54 @@
   1.396        <informalfigure id="fig:concepts:wdir-merge">
   1.397  	<mediaobject><imageobject><imagedata
   1.398  				    fileref="wdir-merge"/></imageobject><textobject><phrase>XXX 
   1.399 -	      add text</phrase></textobject><caption><para>Merging two
   1.400 +	      add text</phrase></textobject><caption><para id="x_318">Merging two
   1.401  	      heads</para></caption></mediaobject>
   1.402        </informalfigure>
   1.403  
   1.404 -      <para>Mercurial also has to modify the working directory, to
   1.405 +      <para id="x_319">Mercurial also has to modify the working directory, to
   1.406  	merge the files managed in the two changesets.  Simplified a
   1.407  	little, the merging process goes like this, for every file in
   1.408  	the manifests of both changesets.</para>
   1.409        <itemizedlist>
   1.410 -	<listitem><para>If neither changeset has modified a file, do
   1.411 +	<listitem><para id="x_31a">If neither changeset has modified a file, do
   1.412  	    nothing with that file.</para>
   1.413  	</listitem>
   1.414 -	<listitem><para>If one changeset has modified a file, and the
   1.415 +	<listitem><para id="x_31b">If one changeset has modified a file, and the
   1.416  	    other hasn't, create the modified copy of the file in the
   1.417  	    working directory.</para>
   1.418  	</listitem>
   1.419 -	<listitem><para>If one changeset has removed a file, and the
   1.420 +	<listitem><para id="x_31c">If one changeset has removed a file, and the
   1.421  	    other hasn't (or has also deleted it), delete the file
   1.422  	    from the working directory.</para>
   1.423  	</listitem>
   1.424 -	<listitem><para>If one changeset has removed a file, but the
   1.425 +	<listitem><para id="x_31d">If one changeset has removed a file, but the
   1.426  	    other has modified the file, ask the user what to do: keep
   1.427  	    the modified file, or remove it?</para>
   1.428  	</listitem>
   1.429 -	<listitem><para>If both changesets have modified a file,
   1.430 +	<listitem><para id="x_31e">If both changesets have modified a file,
   1.431  	    invoke an external merge program to choose the new
   1.432  	    contents for the merged file.  This may require input from
   1.433  	    the user.</para>
   1.434  	</listitem>
   1.435 -	<listitem><para>If one changeset has modified a file, and the
   1.436 +	<listitem><para id="x_31f">If one changeset has modified a file, and the
   1.437  	    other has renamed or copied the file, make sure that the
   1.438  	    changes follow the new name of the file.</para>
   1.439  	</listitem></itemizedlist>
   1.440 -      <para>There are more details&emdash;merging has plenty of corner
   1.441 +      <para id="x_320">There are more details&emdash;merging has plenty of corner
   1.442  	cases&emdash;but these are the most common choices that are
   1.443  	involved in a merge.  As you can see, most cases are
   1.444  	completely automatic, and indeed most merges finish
   1.445  	automatically, without requiring your input to resolve any
   1.446  	conflicts.</para>
   1.447  
   1.448 -      <para>When you're thinking about what happens when you commit
   1.449 +      <para id="x_321">When you're thinking about what happens when you commit
   1.450  	after a merge, once again the working directory is <quote>the
   1.451  	  changeset I'm about to commit</quote>.  After the <command
   1.452  	  role="hg-cmd">hg merge</command> command completes, the
   1.453  	working directory has two parents; these will become the
   1.454  	parents of the new changeset.</para>
   1.455  
   1.456 -      <para>Mercurial lets you perform multiple merges, but you must
   1.457 +      <para id="x_322">Mercurial lets you perform multiple merges, but you must
   1.458  	commit the results of each individual merge as you go.  This
   1.459  	is necessary because Mercurial only tracks two parents for
   1.460  	both revisions and the working directory.  While it would be
   1.461 @@ -514,7 +514,7 @@
   1.462    <sect1>
   1.463      <title>Other interesting design features</title>
   1.464  
   1.465 -    <para>In the sections above, I've tried to highlight some of the
   1.466 +    <para id="x_323">In the sections above, I've tried to highlight some of the
   1.467        most important aspects of Mercurial's design, to illustrate that
   1.468        it pays careful attention to reliability and performance.
   1.469        However, the attention to detail doesn't stop there.  There are
   1.470 @@ -527,13 +527,13 @@
   1.471      <sect2>
   1.472        <title>Clever compression</title>
   1.473  
   1.474 -      <para>When appropriate, Mercurial will store both snapshots and
   1.475 +      <para id="x_324">When appropriate, Mercurial will store both snapshots and
   1.476  	deltas in compressed form.  It does this by always
   1.477  	<emphasis>trying to</emphasis> compress a snapshot or delta,
   1.478  	but only storing the compressed version if it's smaller than
   1.479  	the uncompressed version.</para>
   1.480  
   1.481 -      <para>This means that Mercurial does <quote>the right
   1.482 +      <para id="x_325">This means that Mercurial does <quote>the right
   1.483  	  thing</quote> when storing a file whose native form is
   1.484  	compressed, such as a <literal>zip</literal> archive or a JPEG
   1.485  	image.  When these types of files are compressed a second
   1.486 @@ -541,7 +541,7 @@
   1.487  	once-compressed form, and so Mercurial will store the plain
   1.488  	<literal>zip</literal> or JPEG.</para>
   1.489  
   1.490 -      <para>Deltas between revisions of a compressed file are usually
   1.491 +      <para id="x_326">Deltas between revisions of a compressed file are usually
   1.492  	larger than snapshots of the file, and Mercurial again does
   1.493  	<quote>the right thing</quote> in these cases.  It finds that
   1.494  	such a delta exceeds the threshold at which it should store a
   1.495 @@ -552,7 +552,7 @@
   1.496        <sect3>
   1.497  	<title>Network recompression</title>
   1.498  
   1.499 -	<para>When storing revisions on disk, Mercurial uses the
   1.500 +	<para id="x_327">When storing revisions on disk, Mercurial uses the
   1.501  	  <quote>deflate</quote> compression algorithm (the same one
   1.502  	  used by the popular <literal>zip</literal> archive format),
   1.503  	  which balances good speed with a respectable compression
   1.504 @@ -560,7 +560,7 @@
   1.505  	  network connection, Mercurial uncompresses the compressed
   1.506  	  revision data.</para>
   1.507  
   1.508 -	<para>If the connection is over HTTP, Mercurial recompresses
   1.509 +	<para id="x_328">If the connection is over HTTP, Mercurial recompresses
   1.510  	  the entire stream of data using a compression algorithm that
   1.511  	  gives a better compression ratio (the Burrows-Wheeler
   1.512  	  algorithm from the widely used <literal>bzip2</literal>
   1.513 @@ -570,7 +570,7 @@
   1.514  	  transferred, yielding better network performance over almost
   1.515  	  all kinds of network.</para>
   1.516  
   1.517 -	<para>(If the connection is over <command>ssh</command>,
   1.518 +	<para id="x_329">(If the connection is over <command>ssh</command>,
   1.519  	  Mercurial <emphasis>doesn't</emphasis> recompress the
   1.520  	  stream, because <command>ssh</command> can already do this
   1.521  	  itself.)</para>
   1.522 @@ -580,7 +580,7 @@
   1.523      <sect2>
   1.524        <title>Read/write ordering and atomicity</title>
   1.525  
   1.526 -      <para>Appending to files isn't the whole story when it comes to
   1.527 +      <para id="x_32a">Appending to files isn't the whole story when it comes to
   1.528  	guaranteeing that a reader won't see a partial write.  If you
   1.529  	recall figure <xref linkend="fig:concepts:metadata"/>,
   1.530  	revisions in the
   1.531 @@ -588,12 +588,12 @@
   1.532  	the manifest point to revisions in filelogs.  This hierarchy
   1.533  	is deliberate.</para>
   1.534  
   1.535 -      <para>A writer starts a transaction by writing filelog and
   1.536 +      <para id="x_32b">A writer starts a transaction by writing filelog and
   1.537  	manifest data, and doesn't write any changelog data until
   1.538  	those are finished.  A reader starts by reading changelog
   1.539  	data, then manifest data, followed by filelog data.</para>
   1.540  
   1.541 -      <para>Since the writer has always finished writing filelog and
   1.542 +      <para id="x_32c">Since the writer has always finished writing filelog and
   1.543  	manifest data before it writes to the changelog, a reader will
   1.544  	never read a pointer to a partially written manifest revision
   1.545  	from the changelog, and it will never read a pointer to a
   1.546 @@ -603,7 +603,7 @@
   1.547      <sect2>
   1.548        <title>Concurrent access</title>
   1.549  
   1.550 -      <para>The read/write ordering and atomicity guarantees mean that
   1.551 +      <para id="x_32d">The read/write ordering and atomicity guarantees mean that
   1.552  	Mercurial never needs to <emphasis>lock</emphasis> a
   1.553  	repository when it's reading data, even if the repository is
   1.554  	being written to while the read is occurring. This has a big
   1.555 @@ -612,7 +612,7 @@
   1.556  	safely all at once, no matter whether it's being written to or
   1.557  	not.</para>
   1.558  
   1.559 -      <para>The lockless nature of reading means that if you're
   1.560 +      <para id="x_32e">The lockless nature of reading means that if you're
   1.561  	sharing a repository on a multi-user system, you don't need to
   1.562  	grant other local users permission to
   1.563  	<emphasis>write</emphasis> to your repository in order for
   1.564 @@ -625,7 +625,7 @@
   1.565  	which of course makes for all kinds of nasty and annoying
   1.566  	security and administrative problems.)</para>
   1.567  
   1.568 -      <para>Mercurial uses locks to ensure that only one process can
   1.569 +      <para id="x_32f">Mercurial uses locks to ensure that only one process can
   1.570  	write to a repository at a time (the locking mechanism is safe
   1.571  	even over filesystems that are notoriously hostile to locking,
   1.572  	such as NFS).  If a repository is locked, a writer will wait
   1.573 @@ -639,7 +639,7 @@
   1.574        <sect3>
   1.575  	<title>Safe dirstate access</title>
   1.576  
   1.577 -	<para>As with revision data, Mercurial doesn't take a lock to
   1.578 +	<para id="x_330">As with revision data, Mercurial doesn't take a lock to
   1.579  	  read the dirstate file; it does acquire a lock to write it.
   1.580  	  To avoid the possibility of reading a partially written copy
   1.581  	  of the dirstate file, Mercurial writes to a file with a
   1.582 @@ -654,17 +654,17 @@
   1.583      <sect2>
   1.584        <title>Avoiding seeks</title>
   1.585  
   1.586 -      <para>Critical to Mercurial's performance is the avoidance of
   1.587 +      <para id="x_331">Critical to Mercurial's performance is the avoidance of
   1.588  	seeks of the disk head, since any seek is far more expensive
   1.589  	than even a comparatively large read operation.</para>
   1.590  
   1.591 -      <para>This is why, for example, the dirstate is stored in a
   1.592 +      <para id="x_332">This is why, for example, the dirstate is stored in a
   1.593  	single file.  If there were a dirstate file per directory that
   1.594  	Mercurial tracked, the disk would seek once per directory.
   1.595  	Instead, Mercurial reads the entire single dirstate file in
   1.596  	one step.</para>
   1.597  
   1.598 -      <para>Mercurial also uses a <quote>copy on write</quote> scheme
   1.599 +      <para id="x_333">Mercurial also uses a <quote>copy on write</quote> scheme
   1.600  	when cloning a repository on local storage.  Instead of
   1.601  	copying every revlog file from the old repository into the new
   1.602  	repository, it makes a <quote>hard link</quote>, which is a
   1.603 @@ -675,7 +675,7 @@
   1.604  	one repository is using the file, so Mercurial makes a new
   1.605  	copy of the file that is private to this repository.</para>
   1.606  
   1.607 -      <para>A few revision control developers have pointed out that
   1.608 +      <para id="x_334">A few revision control developers have pointed out that
   1.609  	this idea of making a complete private copy of a file is not
   1.610  	very efficient in its use of storage.  While this is true,
   1.611  	storage is cheap, and this method gives the highest
   1.612 @@ -689,21 +689,21 @@
   1.613      <sect2>
   1.614        <title>Other contents of the dirstate</title>
   1.615  
   1.616 -      <para>Because Mercurial doesn't force you to tell it when you're
   1.617 +      <para id="x_335">Because Mercurial doesn't force you to tell it when you're
   1.618  	modifying a file, it uses the dirstate to store some extra
   1.619  	information so it can determine efficiently whether you have
   1.620  	modified a file.  For each file in the working directory, it
   1.621  	stores the time that it last modified the file itself, and the
   1.622  	size of the file at that time.</para>
   1.623  
   1.624 -      <para>When you explicitly <command role="hg-cmd">hg
   1.625 +      <para id="x_336">When you explicitly <command role="hg-cmd">hg
   1.626  	  add</command>, <command role="hg-cmd">hg remove</command>,
   1.627  	<command role="hg-cmd">hg rename</command> or <command
   1.628  	  role="hg-cmd">hg copy</command> files, Mercurial updates the
   1.629  	dirstate so that it knows what to do with those files when you
   1.630  	commit.</para>
   1.631  
   1.632 -      <para>When Mercurial is checking the states of files in the
   1.633 +      <para id="x_337">When Mercurial is checking the states of files in the
   1.634  	working directory, it first checks a file's modification time.
   1.635  	If that has not changed, the file must not have been modified.
   1.636  	If the file's size has changed, the file must have been