1.1 --- a/en/ch04-daily.xml	Sun Apr 12 00:05:30 2009 -0700
     1.2 +++ b/en/ch04-daily.xml	Thu Apr 16 23:46:45 2009 -0700
     1.3 @@ -357,7 +357,7 @@
     1.4  	<emphasis>destination</emphasis>, and all others are
     1.5  	<emphasis>sources</emphasis>.</para>
     1.6  
     1.7 -      <para>If you pass <command role="hg-cmd">hg copy</command> a
     1.8 +      <para id="x_685">If you pass <command role="hg-cmd">hg copy</command> a
     1.9  	single file as the source, and the destination does not exist,
    1.10  	it creates a new file with that name.</para>
    1.11  
    1.12 @@ -430,7 +430,7 @@
    1.13        similar to the <command role="hg-cmd">hg copy</command>
    1.14        command.</para>
    1.15  
    1.16 -    <para>If you're familiar with the Unix command line, you'll be
    1.17 +    <para id="x_686">If you're familiar with the Unix command line, you'll be
    1.18        glad to know that <command role="hg-cmd">hg rename</command>
    1.19        command can be invoked as <command role="hg-cmd">hg
    1.20  	mv</command>.</para>
    1.21 @@ -550,37 +550,37 @@
    1.22    <sect1>
    1.23      <title>Dealing with tricky merges</title>
    1.24  
    1.25 -    <para>In a complicated or large project, it's not unusual for a
    1.26 +    <para id="x_687">In a complicated or large project, it's not unusual for a
    1.27        merge of two changesets to result in some headaches.  Suppose
    1.28        there's a big source file that's been extensively edited by each
    1.29        side of a merge: this is almost inevitably going to result in
    1.30        conflicts, some of which can take a few tries to sort
    1.31        out.</para>
    1.32  
    1.33 -    <para>Let's develop a simple case of this and see how to deal with
    1.34 +    <para id="x_688">Let's develop a simple case of this and see how to deal with
    1.35        it.  We'll start off with a repository containing one file, and
    1.36        clone it twice.</para>
    1.37  
    1.38      &interaction.ch04-resolve.init;
    1.39  
    1.40 -    <para>In one clone, we'll modify the file in one way.</para>
    1.41 +    <para id="x_689">In one clone, we'll modify the file in one way.</para>
    1.42  
    1.43      &interaction.ch04-resolve.left;
    1.44  
    1.45 -    <para>In another, we'll modify the file differently.</para>
    1.46 +    <para id="x_68a">In another, we'll modify the file differently.</para>
    1.47  
    1.48      &interaction.ch04-resolve.right;
    1.49  
    1.50 -    <para>Next, we'll pull each set of changes into our original
    1.51 +    <para id="x_68b">Next, we'll pull each set of changes into our original
    1.52        repo.</para>
    1.53  
    1.54      &interaction.ch04-resolve.pull;
    1.55  
    1.56 -    <para>We expect our repository to now contain two heads.</para>
    1.57 +    <para id="x_68c">We expect our repository to now contain two heads.</para>
    1.58  
    1.59      &interaction.ch04-resolve.heads;
    1.60  
    1.61 -    <para>Normally, if we run <command role="hg-cmd">hg
    1.62 +    <para id="x_68d">Normally, if we run <command role="hg-cmd">hg
    1.63  	merge</command> at this point, it will drop us into a GUI that
    1.64        will let us manually resolve the conflicting edits to
    1.65        <filename>myfile.txt</filename>.  However, to simplify things
    1.66 @@ -589,24 +589,24 @@
    1.67  
    1.68      &interaction.ch04-resolve.export;
    1.69  
    1.70 -    <para>We've told Mercurial's merge machinery to run the command
    1.71 +    <para id="x_68e">We've told Mercurial's merge machinery to run the command
    1.72        <command>false</command> (which, as we desire, fails
    1.73        immediately) if it detects a merge that it can't sort out
    1.74        automatically.</para>
    1.75  
    1.76 -    <para>If we now fire up <command role="hg-cmd">hg
    1.77 +    <para id="x_68f">If we now fire up <command role="hg-cmd">hg
    1.78  	merge</command>, it should grind to a halt and report a
    1.79  	failure.</para>
    1.80  
    1.81      &interaction.ch04-resolve.merge;
    1.82  
    1.83 -    <para>Even if we don't notice that the merge failed, Mercurial
    1.84 +    <para id="x_690">Even if we don't notice that the merge failed, Mercurial
    1.85        will prevent us from accidentally committing the result of a
    1.86        failed merge.</para>
    1.87  
    1.88      &interaction.ch04-resolve.cifail;
    1.89  
    1.90 -    <para>When <command role="hg-cmd">hg commit</command> fails in
    1.91 +    <para id="x_691">When <command role="hg-cmd">hg commit</command> fails in
    1.92        this case, it suggests that we use the unfamiliar <command
    1.93  	role="hg-cmd">hg resolve</command> command.  As usual,
    1.94  	<command role="hg-cmd">hg help resolve</command> will print a
    1.95 @@ -615,35 +615,35 @@
    1.96      <sect2>
    1.97        <title>File resolution states</title>
    1.98  
    1.99 -      <para>When a merge occurs, most files will usually remain
   1.100 +      <para id="x_692">When a merge occurs, most files will usually remain
   1.101  	unmodified.  For each file where Mercurial has to do
   1.102  	something, it tracks the state of the file.</para>
   1.103  
   1.104        <itemizedlist>
   1.105  	<listitem>
   1.106 -	  <para>A <emphasis>resolved</emphasis> file has been
   1.107 +	  <para id="x_693">A <emphasis>resolved</emphasis> file has been
   1.108  	    successfully merged, either automatically by Mercurial or
   1.109  	    manually with human intervention.</para>
   1.110  	</listitem>
   1.111  	<listitem>
   1.112 -	  <para>An <emphasis>unresolved</emphasis> file was not merged
   1.113 +	  <para id="x_694">An <emphasis>unresolved</emphasis> file was not merged
   1.114  	    successfully, and needs more attention.</para>
   1.115  	</listitem>
   1.116        </itemizedlist>
   1.117  
   1.118 -      <para>If Mercurial sees <emphasis>any</emphasis> file in the
   1.119 +      <para id="x_695">If Mercurial sees <emphasis>any</emphasis> file in the
   1.120  	unresolved state after a merge, it considers the merge to have
   1.121  	failed.  Fortunately, we do not need to restart the entire
   1.122  	merge from scratch.</para>
   1.123  
   1.124 -      <para>The <option role="hg-opt-resolve">--list</option> or
   1.125 +      <para id="x_696">The <option role="hg-opt-resolve">--list</option> or
   1.126  	<option role="hg-opt-resolve">-l</option> option to <command
   1.127  	  role="hg-cmd">hg resolve</command> prints out the state of
   1.128  	each merged file.</para>
   1.129  
   1.130        &interaction.ch04-resolve.list;
   1.131  
   1.132 -      <para>In the output from <command role="hg-cmd">hg
   1.133 +      <para id="x_697">In the output from <command role="hg-cmd">hg
   1.134  	  resolve</command>, a resolved file is marked with
   1.135  	<literal>R</literal>, while an unresolved file is marked with
   1.136  	<literal>U</literal>.  If any files are listed with
   1.137 @@ -654,7 +654,7 @@
   1.138      <sect2>
   1.139        <title>Resolving a file merge</title>
   1.140  
   1.141 -      <para>We have several options to move a file from the unresolved
   1.142 +      <para id="x_698">We have several options to move a file from the unresolved
   1.143  	into the resolved state.  By far the most common is to rerun
   1.144  	<command role="hg-cmd">hg resolve</command>.  If we pass the
   1.145  	names of individual files or directories, it will retry the
   1.146 @@ -664,7 +664,7 @@
   1.147  	will retry the merges of <emphasis>all</emphasis> unresolved
   1.148  	files.</para>
   1.149  
   1.150 -      <para>Mercurial also lets us modify the resolution state of a
   1.151 +      <para id="x_699">Mercurial also lets us modify the resolution state of a
   1.152  	file directly.  We can manually mark a file as resolved using
   1.153  	the <option role="hg-opt-resolve">--mark</option> option, or
   1.154  	as unresolved using the <option