1.1 --- a/en/ch04-daily.xml	Thu Mar 19 20:54:12 2009 -0700
     1.2 +++ b/en/ch04-daily.xml	Thu Mar 19 21:18:52 2009 -0700
     1.3 @@ -7,14 +7,14 @@
     1.4    <sect1>
     1.5      <title>Telling Mercurial which files to track</title>
     1.6  
     1.7 -    <para>Mercurial does not work with files in your repository unless
     1.8 +    <para id="x_1a3">Mercurial does not work with files in your repository unless
     1.9        you tell it to manage them.  The <command role="hg-cmd">hg
    1.10  	status</command> command will tell you which files Mercurial
    1.11        doesn't know about; it uses a
    1.12        <quote><literal>?</literal></quote> to display such
    1.13        files.</para>
    1.14  
    1.15 -    <para>To tell Mercurial to track a file, use the <command
    1.16 +    <para id="x_1a4">To tell Mercurial to track a file, use the <command
    1.17  	role="hg-cmd">hg add</command> command.  Once you have added a
    1.18        file, the entry in the output of <command role="hg-cmd">hg
    1.19  	status</command> for that file changes from
    1.20 @@ -23,7 +23,7 @@
    1.21  
    1.22        &interaction.daily.files.add;
    1.23  
    1.24 -    <para>After you run a <command role="hg-cmd">hg commit</command>,
    1.25 +    <para id="x_1a5">After you run a <command role="hg-cmd">hg commit</command>,
    1.26        the files that you added before the commit will no longer be
    1.27        listed in the output of <command role="hg-cmd">hg
    1.28  	status</command>.  The reason for this is that <command
    1.29 @@ -35,7 +35,7 @@
    1.30        is tracking, but that have not changed.  (You can still get this
    1.31        information; we'll return to this later.)</para>
    1.32  
    1.33 -    <para>Once you add a file, Mercurial doesn't do anything with it
    1.34 +    <para id="x_1a6">Once you add a file, Mercurial doesn't do anything with it
    1.35        immediately.  Instead, it will take a snapshot of the file's
    1.36        state the next time you perform a commit.  It will then continue
    1.37        to track the changes you make to the file every time you commit,
    1.38 @@ -44,24 +44,24 @@
    1.39      <sect2>
    1.40        <title>Explicit versus implicit file naming</title>
    1.41  
    1.42 -      <para>A useful behaviour that Mercurial has is that if you pass
    1.43 +      <para id="x_1a7">A useful behaviour that Mercurial has is that if you pass
    1.44  	the name of a directory to a command, every Mercurial command
    1.45  	will treat this as <quote>I want to operate on every file in
    1.46  	  this directory and its subdirectories</quote>.</para>
    1.47  
    1.48        &interaction.daily.files.add-dir;
    1.49  
    1.50 -      <para>Notice in this example that Mercurial printed the names of
    1.51 +      <para id="x_1a8">Notice in this example that Mercurial printed the names of
    1.52  	the files it added, whereas it didn't do so when we added the
    1.53  	file named <filename>a</filename> in the earlier
    1.54  	example.</para>
    1.55  
    1.56 -      <para>What's going on is that in the former case, we explicitly
    1.57 +      <para id="x_1a9">What's going on is that in the former case, we explicitly
    1.58  	named the file to add on the command line, so the assumption
    1.59  	that Mercurial makes in such cases is that you know what you
    1.60  	were doing, and it doesn't print any output.</para>
    1.61  
    1.62 -      <para>However, when we <emphasis>imply</emphasis> the names of
    1.63 +      <para id="x_1aa">However, when we <emphasis>imply</emphasis> the names of
    1.64  	files by giving the name of a directory, Mercurial takes the
    1.65  	extra step of printing the name of each file that it does
    1.66  	something with.  This makes it more clear what is happening,
    1.67 @@ -72,7 +72,7 @@
    1.68      <sect2>
    1.69        <title>Aside: Mercurial tracks files, not directories</title>
    1.70  
    1.71 -      <para>Mercurial does not track directory information.  Instead,
    1.72 +      <para id="x_1ab">Mercurial does not track directory information.  Instead,
    1.73  	it tracks the path to a file.  Before creating a file, it
    1.74  	first creates any missing directory components of the path.
    1.75  	After it deletes a file, it then deletes any empty directories
    1.76 @@ -81,14 +81,14 @@
    1.77  	consequence: it is not possible to represent a completely
    1.78  	empty directory in Mercurial.</para>
    1.79  
    1.80 -      <para>Empty directories are rarely useful, and there are
    1.81 +      <para id="x_1ac">Empty directories are rarely useful, and there are
    1.82  	unintrusive workarounds that you can use to achieve an
    1.83  	appropriate effect.  The developers of Mercurial thus felt
    1.84  	that the complexity that would be required to manage empty
    1.85  	directories was not worth the limited benefit this feature
    1.86  	would bring.</para>
    1.87  
    1.88 -      <para>If you need an empty directory in your repository, there
    1.89 +      <para id="x_1ad">If you need an empty directory in your repository, there
    1.90  	are a few ways to achieve this. One is to create a directory,
    1.91  	then <command role="hg-cmd">hg add</command> a
    1.92  	<quote>hidden</quote> file to that directory.  On Unix-like
    1.93 @@ -99,7 +99,7 @@
    1.94  
    1.95  &interaction.daily.files.hidden;
    1.96  
    1.97 -      <para>Another way to tackle a need for an empty directory is to
    1.98 +      <para id="x_1ae">Another way to tackle a need for an empty directory is to
    1.99  	simply create one in your automated build scripts before they
   1.100  	will need it.</para>
   1.101  
   1.102 @@ -108,7 +108,7 @@
   1.103    <sect1>
   1.104      <title>How to stop tracking a file</title>
   1.105  
   1.106 -    <para>Once you decide that a file no longer belongs in your
   1.107 +    <para id="x_1af">Once you decide that a file no longer belongs in your
   1.108        repository, use the <command role="hg-cmd">hg remove</command>
   1.109        command; this deletes the file, and tells Mercurial to stop
   1.110        tracking it.  A removed file is represented in the output of
   1.111 @@ -117,7 +117,7 @@
   1.112  
   1.113      &interaction.daily.files.remove;
   1.114  
   1.115 -    <para>After you <command role="hg-cmd">hg remove</command> a file,
   1.116 +    <para id="x_1b0">After you <command role="hg-cmd">hg remove</command> a file,
   1.117        Mercurial will no longer track changes to that file, even if you
   1.118        recreate a file with the same name in your working directory.
   1.119        If you do recreate a file with the same name and want Mercurial
   1.120 @@ -128,19 +128,19 @@
   1.121      <sect2>
   1.122        <title>Removing a file does not affect its history</title>
   1.123  
   1.124 -      <para>It is important to understand that removing a file has
   1.125 +      <para id="x_1b1">It is important to understand that removing a file has
   1.126  	only two effects.</para>
   1.127        <itemizedlist>
   1.128 -	<listitem><para>It removes the current version of the file
   1.129 +	<listitem><para id="x_1b2">It removes the current version of the file
   1.130  	    from the working directory.</para>
   1.131  	</listitem>
   1.132 -	<listitem><para>It stops Mercurial from tracking changes to
   1.133 +	<listitem><para id="x_1b3">It stops Mercurial from tracking changes to
   1.134  	    the file, from the time of the next commit.</para>
   1.135  	</listitem></itemizedlist>
   1.136 -      <para>Removing a file <emphasis>does not</emphasis> in any way
   1.137 +      <para id="x_1b4">Removing a file <emphasis>does not</emphasis> in any way
   1.138  	alter the <emphasis>history</emphasis> of the file.</para>
   1.139  
   1.140 -      <para>If you update the working directory to a changeset in
   1.141 +      <para id="x_1b5">If you update the working directory to a changeset in
   1.142  	which a file that you have removed was still tracked, it will
   1.143  	reappear in the working directory, with the contents it had
   1.144  	when you committed that changeset.  If you then update the
   1.145 @@ -152,7 +152,7 @@
   1.146      <sect2>
   1.147        <title>Missing files</title>
   1.148  
   1.149 -      <para>Mercurial considers a file that you have deleted, but not
   1.150 +      <para id="x_1b6">Mercurial considers a file that you have deleted, but not
   1.151  	used <command role="hg-cmd">hg remove</command> to delete, to
   1.152  	be <emphasis>missing</emphasis>.  A missing file is
   1.153  	represented with <quote><literal>!</literal></quote> in the
   1.154 @@ -162,7 +162,7 @@
   1.155  
   1.156        &interaction.daily.files.missing;
   1.157  
   1.158 -      <para>If your repository contains a file that <command
   1.159 +      <para id="x_1b7">If your repository contains a file that <command
   1.160  	  role="hg-cmd">hg status</command> reports as missing, and
   1.161  	you want the file to stay gone, you can run <command
   1.162  	  role="hg-cmd">hg remove <option
   1.163 @@ -172,7 +172,7 @@
   1.164  
   1.165        &interaction.daily.files.remove-after;
   1.166  
   1.167 -      <para>On the other hand, if you deleted the missing file by
   1.168 +      <para id="x_1b8">On the other hand, if you deleted the missing file by
   1.169  	accident, give <command role="hg-cmd">hg revert</command> the
   1.170  	name of the file to recover.  It will reappear, in unmodified
   1.171  	form.</para>
   1.172 @@ -184,7 +184,7 @@
   1.173        <title>Aside: why tell Mercurial explicitly to remove a
   1.174  	file?</title>
   1.175  
   1.176 -      <para>You might wonder why Mercurial requires you to explicitly
   1.177 +      <para id="x_1b9">You might wonder why Mercurial requires you to explicitly
   1.178  	tell it that you are deleting a file.  Early during the
   1.179  	development of Mercurial, it let you delete a file however you
   1.180  	pleased; Mercurial would notice the absence of the file
   1.181 @@ -198,13 +198,13 @@
   1.182        <title>Useful shorthand&emdash;adding and removing files in one
   1.183  	step</title>
   1.184  
   1.185 -      <para>Mercurial offers a combination command, <command
   1.186 +      <para id="x_1ba">Mercurial offers a combination command, <command
   1.187  	  role="hg-cmd">hg addremove</command>, that adds untracked
   1.188  	files and marks missing files as removed.</para>
   1.189  
   1.190        &interaction.daily.files.addremove;
   1.191  
   1.192 -      <para>The <command role="hg-cmd">hg commit</command> command
   1.193 +      <para id="x_1bb">The <command role="hg-cmd">hg commit</command> command
   1.194  	also provides a <option role="hg-opt-commit">-A</option>
   1.195  	option that performs this same add-and-remove, immediately
   1.196  	followed by a commit.</para>
   1.197 @@ -216,7 +216,7 @@
   1.198    <sect1>
   1.199      <title>Copying files</title>
   1.200  
   1.201 -    <para>Mercurial provides a <command role="hg-cmd">hg
   1.202 +    <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg
   1.203  	copy</command> command that lets you make a new copy of a
   1.204        file.  When you copy a file using this command, Mercurial makes
   1.205        a record of the fact that the new file is a copy of the original
   1.206 @@ -226,32 +226,32 @@
   1.207      <sect2>
   1.208        <title>The results of copying during a merge</title>
   1.209  
   1.210 -      <para>What happens during a merge is that changes
   1.211 +      <para id="x_1bd">What happens during a merge is that changes
   1.212  	<quote>follow</quote> a copy.  To best illustrate what this
   1.213  	means, let's create an example.  We'll start with the usual
   1.214  	tiny repository that contains a single file.</para>
   1.215  
   1.216        &interaction.daily.copy.init;
   1.217  
   1.218 -      <para>We need to do some work in
   1.219 +      <para id="x_1be">We need to do some work in
   1.220  	parallel, so that we'll have something to merge.  So let's
   1.221  	clone our repository.</para>
   1.222  
   1.223        &interaction.daily.copy.clone;
   1.224  
   1.225 -      <para>Back in our initial repository, let's use the <command
   1.226 +      <para id="x_1bf">Back in our initial repository, let's use the <command
   1.227  	  role="hg-cmd">hg copy</command> command to make a copy of
   1.228  	the first file we created.</para>
   1.229  
   1.230        &interaction.daily.copy.copy;
   1.231  
   1.232 -      <para>If we look at the output of the <command role="hg-cmd">hg
   1.233 +      <para id="x_1c0">If we look at the output of the <command role="hg-cmd">hg
   1.234  	  status</command> command afterwards, the copied file looks
   1.235  	just like a normal added file.</para>
   1.236  
   1.237        &interaction.daily.copy.status;
   1.238  
   1.239 -      <para>But if we pass the <option
   1.240 +      <para id="x_1c1">But if we pass the <option
   1.241  	  role="hg-opt-status">-C</option> option to <command
   1.242  	  role="hg-cmd">hg status</command>, it prints another line of
   1.243  	output: this is the file that our newly-added file was copied
   1.244 @@ -259,13 +259,13 @@
   1.245  
   1.246        &interaction.daily.copy.status-copy;
   1.247  
   1.248 -      <para>Now, back in the repository we cloned, let's make a change
   1.249 +      <para id="x_1c2">Now, back in the repository we cloned, let's make a change
   1.250  	in parallel.  We'll add a line of content to the original file
   1.251  	that we created.</para>
   1.252  
   1.253        &interaction.daily.copy.other;
   1.254  
   1.255 -      <para>Now we have a modified <filename>file</filename> in this
   1.256 +      <para id="x_1c3">Now we have a modified <filename>file</filename> in this
   1.257  	repository.  When we pull the changes from the first
   1.258  	repository, and merge the two heads, Mercurial will propagate
   1.259  	the changes that we made locally to <filename>file</filename>
   1.260 @@ -277,41 +277,41 @@
   1.261      <sect2 id="sec:daily:why-copy">
   1.262        <title>Why should changes follow copies?</title>
   1.263  
   1.264 -      <para>This behaviour, of changes to a file propagating out to
   1.265 +      <para id="x_1c4">This behaviour, of changes to a file propagating out to
   1.266  	copies of the file, might seem esoteric, but in most cases
   1.267  	it's highly desirable.</para>
   1.268  
   1.269 -      <para>First of all, remember that this propagation
   1.270 +      <para id="x_1c5">First of all, remember that this propagation
   1.271  	<emphasis>only</emphasis> happens when you merge.  So if you
   1.272  	<command role="hg-cmd">hg copy</command> a file, and
   1.273  	subsequently modify the original file during the normal course
   1.274  	of your work, nothing will happen.</para>
   1.275  
   1.276 -      <para>The second thing to know is that modifications will only
   1.277 +      <para id="x_1c6">The second thing to know is that modifications will only
   1.278  	propagate across a copy as long as the repository that you're
   1.279  	pulling changes from <emphasis>doesn't know</emphasis> about
   1.280  	the copy.</para>
   1.281  
   1.282 -      <para>The reason that Mercurial does this is as follows.  Let's
   1.283 +      <para id="x_1c7">The reason that Mercurial does this is as follows.  Let's
   1.284  	say I make an important bug fix in a source file, and commit
   1.285  	my changes. Meanwhile, you've decided to <command
   1.286  	  role="hg-cmd">hg copy</command> the file in your repository,
   1.287  	without knowing about the bug or having seen the fix, and you
   1.288  	have started hacking on your copy of the file.</para>
   1.289  
   1.290 -      <para>If you pulled and merged my changes, and Mercurial
   1.291 +      <para id="x_1c8">If you pulled and merged my changes, and Mercurial
   1.292  	<emphasis>didn't</emphasis> propagate changes across copies,
   1.293  	your source file would now contain the bug, and unless you
   1.294  	remembered to propagate the bug fix by hand, the bug would
   1.295  	<emphasis>remain</emphasis> in your copy of the file.</para>
   1.296  
   1.297 -      <para>By automatically propagating the change that fixed the bug
   1.298 +      <para id="x_1c9">By automatically propagating the change that fixed the bug
   1.299  	from the original file to the copy, Mercurial prevents this
   1.300  	class of problem. To my knowledge, Mercurial is the
   1.301  	<emphasis>only</emphasis> revision control system that
   1.302  	propagates changes across copies like this.</para>
   1.303  
   1.304 -      <para>Once your change history has a record that the copy and
   1.305 +      <para id="x_1ca">Once your change history has a record that the copy and
   1.306  	subsequent merge occurred, there's usually no further need to
   1.307  	propagate changes from the original file to the copied file,
   1.308  	and that's why Mercurial only propagates changes across copies
   1.309 @@ -322,7 +322,7 @@
   1.310        <title>How to make changes <emphasis>not</emphasis> follow a
   1.311  	copy</title>
   1.312  
   1.313 -      <para>If, for some reason, you decide that this business of
   1.314 +      <para id="x_1cb">If, for some reason, you decide that this business of
   1.315  	automatically propagating changes across copies is not for
   1.316  	you, simply use your system's normal file copy command (on
   1.317  	Unix-like systems, that's <command>cp</command>) to make a
   1.318 @@ -338,7 +338,7 @@
   1.319        <title>Behaviour of the <command role="hg-cmd">hg copy</command>
   1.320  	command</title>
   1.321  
   1.322 -      <para>When you use the <command role="hg-cmd">hg copy</command>
   1.323 +      <para id="x_1cc">When you use the <command role="hg-cmd">hg copy</command>
   1.324  	command, Mercurial makes a copy of each source file as it
   1.325  	currently stands in the working directory.  This means that if
   1.326  	you make some modifications to a file, then <command
   1.327 @@ -348,7 +348,7 @@
   1.328  	behaviour a little counterintuitive, which is why I mention it
   1.329  	here.)</para>
   1.330  
   1.331 -      <para>The <command role="hg-cmd">hg copy</command> command acts
   1.332 +      <para id="x_1cd">The <command role="hg-cmd">hg copy</command> command acts
   1.333  	similarly to the Unix <command>cp</command> command (you can
   1.334  	use the <command role="hg-cmd">hg cp</command> alias if you
   1.335  	prefer).  The last argument is the
   1.336 @@ -359,23 +359,23 @@
   1.337  
   1.338        &interaction.daily.copy.simple;
   1.339        
   1.340 -      <para>If the destination is a directory, Mercurial copies its
   1.341 +      <para id="x_1ce">If the destination is a directory, Mercurial copies its
   1.342  	sources into that directory.</para>
   1.343  
   1.344        &interaction.daily.copy.dir-dest;
   1.345  
   1.346 -      <para>Copying a directory is
   1.347 +      <para id="x_1cf">Copying a directory is
   1.348  	recursive, and preserves the directory structure of the
   1.349  	source.</para>
   1.350  
   1.351        &interaction.daily.copy.dir-src;
   1.352  
   1.353 -      <para>If the source and destination are both directories, the
   1.354 +      <para id="x_1d0">If the source and destination are both directories, the
   1.355  	source tree is recreated in the destination directory.</para>
   1.356  
   1.357  	&interaction.daily.copy.dir-src-dest;
   1.358  
   1.359 -      <para>As with the <command role="hg-cmd">hg rename</command>
   1.360 +      <para id="x_1d1">As with the <command role="hg-cmd">hg rename</command>
   1.361  	command, if you copy a file manually and then want Mercurial
   1.362  	to know that you've copied the file, simply use the <option
   1.363  	  role="hg-opt-copy">--after</option> option to <command
   1.364 @@ -388,7 +388,7 @@
   1.365    <sect1>
   1.366      <title>Renaming files</title>
   1.367  
   1.368 -    <para>It's rather more common to need to rename a file than to
   1.369 +    <para id="x_1d2">It's rather more common to need to rename a file than to
   1.370        make a copy of it.  The reason I discussed the <command
   1.371  	role="hg-cmd">hg copy</command> command before talking about
   1.372        renaming files is that Mercurial treats a rename in essentially
   1.373 @@ -396,19 +396,19 @@
   1.374        when you copy a file tells you what to expect when you rename a
   1.375        file.</para>
   1.376  
   1.377 -    <para>When you use the <command role="hg-cmd">hg rename</command>
   1.378 +    <para id="x_1d3">When you use the <command role="hg-cmd">hg rename</command>
   1.379        command, Mercurial makes a copy of each source file, then
   1.380        deletes it and marks the file as removed.</para>
   1.381  
   1.382        &interaction.daily.rename.rename;
   1.383  
   1.384 -    <para>The <command role="hg-cmd">hg status</command> command shows
   1.385 +    <para id="x_1d4">The <command role="hg-cmd">hg status</command> command shows
   1.386        the newly copied file as added, and the copied-from file as
   1.387        removed.</para>
   1.388  
   1.389      &interaction.daily.rename.status;
   1.390  
   1.391 -    <para>As with the results of a <command role="hg-cmd">hg
   1.392 +    <para id="x_1d5">As with the results of a <command role="hg-cmd">hg
   1.393  	copy</command>, we must use the <option
   1.394  	role="hg-opt-status">-C</option> option to <command
   1.395  	role="hg-cmd">hg status</command> to see that the added file
   1.396 @@ -417,7 +417,7 @@
   1.397  
   1.398      &interaction.daily.rename.status-copy;
   1.399  
   1.400 -    <para>As with <command role="hg-cmd">hg remove</command> and
   1.401 +    <para id="x_1d6">As with <command role="hg-cmd">hg remove</command> and
   1.402        <command role="hg-cmd">hg copy</command>, you can tell Mercurial
   1.403        about a rename after the fact using the <option
   1.404  	role="hg-opt-rename">--after</option> option.  In most other
   1.405 @@ -429,18 +429,18 @@
   1.406      <sect2>
   1.407        <title>Renaming files and merging changes</title>
   1.408  
   1.409 -      <para>Since Mercurial's rename is implemented as
   1.410 +      <para id="x_1d7">Since Mercurial's rename is implemented as
   1.411  	copy-and-remove, the same propagation of changes happens when
   1.412  	you merge after a rename as after a copy.</para>
   1.413  
   1.414 -      <para>If I modify a file, and you rename it to a new name, and
   1.415 +      <para id="x_1d8">If I modify a file, and you rename it to a new name, and
   1.416  	then we merge our respective changes, my modifications to the
   1.417  	file under its original name will be propagated into the file
   1.418  	under its new name. (This is something you might expect to
   1.419  	<quote>simply work,</quote> but not all revision control
   1.420  	systems actually do this.)</para>
   1.421  
   1.422 -      <para>Whereas having changes follow a copy is a feature where
   1.423 +      <para id="x_1d9">Whereas having changes follow a copy is a feature where
   1.424  	you can perhaps nod and say <quote>yes, that might be
   1.425  	  useful,</quote> it should be clear that having them follow a
   1.426  	rename is definitely important.  Without this facility, it
   1.427 @@ -451,34 +451,34 @@
   1.428      <sect2>
   1.429        <title>Divergent renames and merging</title>
   1.430  
   1.431 -      <para>The case of diverging names occurs when two developers
   1.432 +      <para id="x_1da">The case of diverging names occurs when two developers
   1.433  	start with a file&emdash;let's call it
   1.434  	<filename>foo</filename>&emdash;in their respective
   1.435  	repositories.</para>
   1.436  
   1.437        &interaction.rename.divergent.clone;
   1.438  
   1.439 -      <para>Anne renames the file to <filename>bar</filename>.</para>
   1.440 +      <para id="x_1db">Anne renames the file to <filename>bar</filename>.</para>
   1.441  
   1.442        &interaction.rename.divergent.rename.anne;
   1.443  
   1.444 -      <para>Meanwhile, Bob renames it to
   1.445 +      <para id="x_1dc">Meanwhile, Bob renames it to
   1.446  	<filename>quux</filename>.</para>
   1.447  
   1.448  	&interaction.rename.divergent.rename.bob;
   1.449  
   1.450 -      <para>I like to think of this as a conflict because each
   1.451 +      <para id="x_1dd">I like to think of this as a conflict because each
   1.452  	developer has expressed different intentions about what the
   1.453  	file ought to be named.</para>
   1.454  
   1.455 -      <para>What do you think should happen when they merge their
   1.456 +      <para id="x_1de">What do you think should happen when they merge their
   1.457  	work? Mercurial's actual behaviour is that it always preserves
   1.458  	<emphasis>both</emphasis> names when it merges changesets that
   1.459  	contain divergent renames.</para>
   1.460  
   1.461        &interaction.rename.divergent.merge;
   1.462  
   1.463 -      <para>Notice that Mercurial does warn about the divergent
   1.464 +      <para id="x_1df">Notice that Mercurial does warn about the divergent
   1.465  	renames, but it leaves it up to you to do something about the
   1.466  	divergence after the merge.</para>
   1.467  
   1.468 @@ -486,7 +486,7 @@
   1.469      <sect2>
   1.470        <title>Convergent renames and merging</title>
   1.471  
   1.472 -      <para>Another kind of rename conflict occurs when two people
   1.473 +      <para id="x_1e0">Another kind of rename conflict occurs when two people
   1.474  	choose to rename different <emphasis>source</emphasis> files
   1.475  	to the same <emphasis>destination</emphasis>. In this case,
   1.476  	Mercurial runs its normal merge machinery, and lets you guide
   1.477 @@ -496,7 +496,7 @@
   1.478      <sect2>
   1.479        <title>Other name-related corner cases</title>
   1.480  
   1.481 -      <para>Mercurial has a longstanding bug in which it fails to
   1.482 +      <para id="x_1e1">Mercurial has a longstanding bug in which it fails to
   1.483  	handle a merge where one side has a file with a given name,
   1.484  	while another has a directory with the same name.  This is
   1.485  	documented as <ulink role="hg-bug"
   1.486 @@ -510,10 +510,10 @@
   1.487    <sect1>
   1.488      <title>Recovering from mistakes</title>
   1.489  
   1.490 -    <para>Mercurial has some useful commands that will help you to
   1.491 +    <para id="x_1e2">Mercurial has some useful commands that will help you to
   1.492        recover from some common mistakes.</para>
   1.493  
   1.494 -    <para>The <command role="hg-cmd">hg revert</command> command lets
   1.495 +    <para id="x_1e3">The <command role="hg-cmd">hg revert</command> command lets
   1.496        you undo changes that you have made to your working directory.
   1.497        For example, if you <command role="hg-cmd">hg add</command> a
   1.498        file by accident, just run <command role="hg-cmd">hg
   1.499 @@ -523,13 +523,13 @@
   1.500        <command role="hg-cmd">hg revert</command> to get rid of
   1.501        erroneous changes to a file.</para>
   1.502  
   1.503 -    <para>It's useful to remember that the <command role="hg-cmd">hg
   1.504 +    <para id="x_1e4">It's useful to remember that the <command role="hg-cmd">hg
   1.505  	revert</command> command is useful for changes that you have
   1.506        not yet committed.  Once you've committed a change, if you
   1.507        decide it was a mistake, you can still do something about it,
   1.508        though your options may be more limited.</para>
   1.509  
   1.510 -    <para>For more information about the <command role="hg-cmd">hg
   1.511 +    <para id="x_1e5">For more information about the <command role="hg-cmd">hg
   1.512  	revert</command> command, and details about how to deal with
   1.513        changes you have already committed, see chapter <xref
   1.514  	linkend="chap:undo"/>.</para>