1.1 --- a/en/ch01-tour-basic.xml	Thu Apr 09 22:54:10 2009 -0700
     1.2 +++ b/en/ch01-tour-basic.xml	Sun Apr 12 00:05:30 2009 -0700
     1.3 @@ -589,7 +589,7 @@
     1.4        <sect3 id="sec:tour-basic:username">
     1.5  	<title>Creating a Mercurial configuration file</title>
     1.6  
     1.7 -	<para id="x_4a">To set a user name, use your favourite editor
     1.8 +	<para id="x_4a">To set a user name, use your favorite editor
     1.9  	    to create a file called <filename
    1.10  	      role="special">.hgrc</filename> in your home directory.
    1.11  	    Mercurial will use this file to look up your personalised

     2.1 --- a/en/ch04-daily.xml	Thu Apr 09 22:54:10 2009 -0700
     2.2 +++ b/en/ch04-daily.xml	Sun Apr 12 00:05:30 2009 -0700
     2.3 @@ -26,14 +26,14 @@
     2.4      <para id="x_1a5">After you run a <command role="hg-cmd">hg commit</command>,
     2.5        the files that you added before the commit will no longer be
     2.6        listed in the output of <command role="hg-cmd">hg
     2.7 -	status</command>.  The reason for this is that <command
     2.8 +	status</command>.  The reason for this is that by default, <command
     2.9  	role="hg-cmd">hg status</command> only tells you about
    2.10 -      <quote>interesting</quote> files&emdash;those that you have
    2.11 -      modified or told Mercurial to do something with&emdash;by
    2.12 -      default.  If you have a repository that contains thousands of
    2.13 -      files, you will rarely want to know about files that Mercurial
    2.14 -      is tracking, but that have not changed.  (You can still get this
    2.15 -      information; we'll return to this later.)</para>
    2.16 +      <quote>interesting</quote> files&emdash;those that you have (for
    2.17 +      example) modified, removed, or renamed.  If you have a repository
    2.18 +      that contains thousands of files, you will rarely want to know
    2.19 +      about files that Mercurial is tracking, but that have not
    2.20 +      changed.  (You can still get this information; we'll return to
    2.21 +      this later.)</para>
    2.22  
    2.23      <para id="x_1a6">Once you add a file, Mercurial doesn't do anything with it
    2.24        immediately.  Instead, it will take a snapshot of the file's
    2.25 @@ -51,15 +51,15 @@
    2.26  
    2.27        &interaction.daily.files.add-dir;
    2.28  
    2.29 -      <para id="x_1a8">Notice in this example that Mercurial printed the names of
    2.30 -	the files it added, whereas it didn't do so when we added the
    2.31 -	file named <filename>a</filename> in the earlier
    2.32 -	example.</para>
    2.33 +      <para id="x_1a8">Notice in this example that Mercurial printed
    2.34 +	the names of the files it added, whereas it didn't do so when
    2.35 +	we added the file named <filename>myfile.txt</filename> in the
    2.36 +	earlier example.</para>
    2.37  
    2.38        <para id="x_1a9">What's going on is that in the former case, we explicitly
    2.39 -	named the file to add on the command line, so the assumption
    2.40 -	that Mercurial makes in such cases is that you know what you
    2.41 -	were doing, and it doesn't print any output.</para>
    2.42 +	named the file to add on the command line.  The assumption
    2.43 +	that Mercurial makes in such cases is that we know what we
    2.44 +	are doing, and it doesn't print any output.</para>
    2.45  
    2.46        <para id="x_1aa">However, when we <emphasis>imply</emphasis> the names of
    2.47  	files by giving the name of a directory, Mercurial takes the
    2.48 @@ -67,8 +67,8 @@
    2.49  	something with.  This makes it more clear what is happening,
    2.50  	and reduces the likelihood of a silent and nasty surprise.
    2.51  	This behavior is common to most Mercurial commands.</para>
    2.52 -
    2.53 -    </sect2>
    2.54 +    </sect2>
    2.55 +
    2.56      <sect2>
    2.57        <title>Mercurial tracks files, not directories</title>
    2.58  
    2.59 @@ -102,15 +102,15 @@
    2.60        <para id="x_1ae">Another way to tackle a need for an empty directory is to
    2.61  	simply create one in your automated build scripts before they
    2.62  	will need it.</para>
    2.63 -
    2.64      </sect2>
    2.65    </sect1>
    2.66 +
    2.67    <sect1>
    2.68      <title>How to stop tracking a file</title>
    2.69  
    2.70      <para id="x_1af">Once you decide that a file no longer belongs in your
    2.71        repository, use the <command role="hg-cmd">hg remove</command>
    2.72 -      command; this deletes the file, and tells Mercurial to stop
    2.73 +      command. This deletes the file, and tells Mercurial to stop
    2.74        tracking it.  A removed file is represented in the output of
    2.75        <command role="hg-cmd">hg status</command> with a
    2.76        <quote><literal>R</literal></quote>.</para>
    2.77 @@ -140,15 +140,16 @@
    2.78        <para id="x_1b4">Removing a file <emphasis>does not</emphasis> in any way
    2.79  	alter the <emphasis>history</emphasis> of the file.</para>
    2.80  
    2.81 -      <para id="x_1b5">If you update the working directory to a changeset in
    2.82 -	which a file that you have removed was still tracked, it will
    2.83 -	reappear in the working directory, with the contents it had
    2.84 -	when you committed that changeset.  If you then update the
    2.85 -	working directory to a later changeset, in which the file had
    2.86 -	been removed, Mercurial will once again remove the file from
    2.87 -	the working directory.</para>
    2.88 -
    2.89 -    </sect2>
    2.90 +      <para id="x_1b5">If you update the working directory to a
    2.91 +	changeset that was committed when it was still tracking a file
    2.92 +	that you later removed, the file will reappear in the working
    2.93 +	directory, with the contents it had when you committed that
    2.94 +	changeset.  If you then update the working directory to a
    2.95 +	later changeset, in which the file had been removed, Mercurial
    2.96 +	will once again remove the file from the working
    2.97 +	directory.</para>
    2.98 +    </sect2>
    2.99 +
   2.100      <sect2>
   2.101        <title>Missing files</title>
   2.102  
   2.103 @@ -177,9 +178,9 @@
   2.104  	name of the file to recover.  It will reappear, in unmodified
   2.105  	form.</para>
   2.106  
   2.107 -&interaction.daily.files.recover-missing;
   2.108 -
   2.109 -    </sect2>
   2.110 +      &interaction.daily.files.recover-missing;
   2.111 +    </sect2>
   2.112 +
   2.113      <sect2>
   2.114        <title>Aside: why tell Mercurial explicitly to remove a
   2.115  	file?</title>
   2.116 @@ -192,8 +193,8 @@
   2.117  	  commit</command>, and stop tracking the file.  In practice,
   2.118  	this made it too easy to accidentally remove a file without
   2.119  	noticing.</para>
   2.120 -
   2.121 -    </sect2>
   2.122 +    </sect2>
   2.123 +
   2.124      <sect2>
   2.125        <title>Useful shorthand&emdash;adding and removing files in one
   2.126  	step</title>
   2.127 @@ -210,9 +211,9 @@
   2.128  	followed by a commit.</para>
   2.129  
   2.130        &interaction.daily.files.commit-addremove;
   2.131 -
   2.132      </sect2>
   2.133    </sect1>
   2.134 +
   2.135    <sect1>
   2.136      <title>Copying files</title>
   2.137  
   2.138 @@ -272,14 +273,14 @@
   2.139  	into its copy, <filename>new-file</filename>.</para>
   2.140  
   2.141        &interaction.daily.copy.merge;
   2.142 -
   2.143 -    </sect2>
   2.144 +    </sect2>
   2.145 +
   2.146      <sect2 id="sec:daily:why-copy">
   2.147        <title>Why should changes follow copies?</title>
   2.148  
   2.149 -      <para id="x_1c4">This behavior, of changes to a file propagating out to
   2.150 -	copies of the file, might seem esoteric, but in most cases
   2.151 -	it's highly desirable.</para>
   2.152 +      <para id="x_1c4">This behavior&emdash;of changes to a file
   2.153 +	propagating out to copies of the file&emdash;might seem
   2.154 +	esoteric, but in most cases it's highly desirable.</para>
   2.155  
   2.156        <para id="x_1c5">First of all, remember that this propagation
   2.157  	<emphasis>only</emphasis> happens when you merge.  So if you
   2.158 @@ -288,8 +289,8 @@
   2.159  	of your work, nothing will happen.</para>
   2.160  
   2.161        <para id="x_1c6">The second thing to know is that modifications will only
   2.162 -	propagate across a copy as long as the repository that you're
   2.163 -	pulling changes from <emphasis>doesn't know</emphasis> about
   2.164 +	propagate across a copy as long as the changeset that you're
   2.165 +	merging changes from <emphasis>hasn't yet seen</emphasis> 
   2.166  	the copy.</para>
   2.167  
   2.168        <para id="x_1c7">The reason that Mercurial does this is as follows.  Let's
   2.169 @@ -301,8 +302,8 @@
   2.170  
   2.171        <para id="x_1c8">If you pulled and merged my changes, and Mercurial
   2.172  	<emphasis>didn't</emphasis> propagate changes across copies,
   2.173 -	your source file would now contain the bug, and unless you
   2.174 -	remembered to propagate the bug fix by hand, the bug would
   2.175 +	your new source file would now contain the bug, and unless you
   2.176 +	knew to propagate the bug fix by hand, the bug would
   2.177  	<emphasis>remain</emphasis> in your copy of the file.</para>
   2.178  
   2.179        <para id="x_1c9">By automatically propagating the change that fixed the bug
   2.180 @@ -315,9 +316,9 @@
   2.181  	subsequent merge occurred, there's usually no further need to
   2.182  	propagate changes from the original file to the copied file,
   2.183  	and that's why Mercurial only propagates changes across copies
   2.184 -	until this point, and no further.</para>
   2.185 -
   2.186 -    </sect2>
   2.187 +	at the first merge, and not afterwards.</para>
   2.188 +    </sect2>
   2.189 +
   2.190      <sect2>
   2.191        <title>How to make changes <emphasis>not</emphasis> follow a
   2.192  	copy</title>
   2.193 @@ -335,7 +336,7 @@
   2.194  
   2.195      </sect2>
   2.196      <sect2>
   2.197 -      <title>Behaviour of the <command role="hg-cmd">hg copy</command>
   2.198 +      <title>Behavior of the <command role="hg-cmd">hg copy</command>
   2.199  	command</title>
   2.200  
   2.201        <para id="x_1cc">When you use the <command role="hg-cmd">hg copy</command>
   2.202 @@ -348,14 +349,17 @@
   2.203  	behavior a little counterintuitive, which is why I mention it
   2.204  	here.)</para>
   2.205  
   2.206 -      <para id="x_1cd">The <command role="hg-cmd">hg copy</command> command acts
   2.207 -	similarly to the Unix <command>cp</command> command (you can
   2.208 -	use the <command role="hg-cmd">hg cp</command> alias if you
   2.209 -	prefer).  The last argument is the
   2.210 -	<emphasis>destination</emphasis>, and all prior arguments are
   2.211 -	<emphasis>sources</emphasis>.  If you pass it a single file as
   2.212 -	the source, and the destination does not exist, it creates a
   2.213 -	new file with that name.</para>
   2.214 +      <para id="x_1cd">The <command role="hg-cmd">hg copy</command>
   2.215 +	command acts similarly to the Unix <command>cp</command>
   2.216 +	command (you can use the <command role="hg-cmd">hg
   2.217 +	  cp</command> alias if you prefer).  We must supply two or
   2.218 +	more arguments, of which the last is treated as the
   2.219 +	<emphasis>destination</emphasis>, and all others are
   2.220 +	<emphasis>sources</emphasis>.</para>
   2.221 +
   2.222 +      <para>If you pass <command role="hg-cmd">hg copy</command> a
   2.223 +	single file as the source, and the destination does not exist,
   2.224 +	it creates a new file with that name.</para>
   2.225  
   2.226        &interaction.daily.copy.simple;
   2.227        
   2.228 @@ -375,16 +379,16 @@
   2.229  
   2.230  	&interaction.daily.copy.dir-src-dest;
   2.231  
   2.232 -      <para id="x_1d1">As with the <command role="hg-cmd">hg rename</command>
   2.233 +      <para id="x_1d1">As with the <command role="hg-cmd">hg remove</command>
   2.234  	command, if you copy a file manually and then want Mercurial
   2.235  	to know that you've copied the file, simply use the <option
   2.236  	  role="hg-opt-copy">--after</option> option to <command
   2.237  	  role="hg-cmd">hg copy</command>.</para>
   2.238  
   2.239        &interaction.daily.copy.after;
   2.240 -
   2.241      </sect2>
   2.242    </sect1>
   2.243 +
   2.244    <sect1>
   2.245      <title>Renaming files</title>
   2.246  
   2.247 @@ -426,6 +430,11 @@
   2.248        similar to the <command role="hg-cmd">hg copy</command>
   2.249        command.</para>
   2.250  
   2.251 +    <para>If you're familiar with the Unix command line, you'll be
   2.252 +      glad to know that <command role="hg-cmd">hg rename</command>
   2.253 +      command can be invoked as <command role="hg-cmd">hg
   2.254 +	mv</command>.</para>
   2.255 +
   2.256      <sect2>
   2.257        <title>Renaming files and merging changes</title>
   2.258  
   2.259 @@ -446,8 +455,8 @@
   2.260  	rename is definitely important.  Without this facility, it
   2.261  	would simply be too easy for changes to become orphaned when
   2.262  	files are renamed.</para>
   2.263 -
   2.264 -    </sect2>
   2.265 +    </sect2>
   2.266 +
   2.267      <sect2>
   2.268        <title>Divergent renames and merging</title>
   2.269  
   2.270 @@ -463,7 +472,9 @@
   2.271        &interaction.rename.divergent.rename.anne;
   2.272  
   2.273        <para id="x_1dc">Meanwhile, Bob renames it to
   2.274 -	<filename>quux</filename>.</para>
   2.275 +	<filename>quux</filename>. (Remember that <command
   2.276 +	  role="hg-cmd">hg mv</command> is an alias for <command
   2.277 +	  role="hg-cmd">hg rename</command>.)</para>
   2.278  
   2.279  	&interaction.rename.divergent.rename.bob;
   2.280  
   2.281 @@ -478,11 +489,11 @@
   2.282  
   2.283        &interaction.rename.divergent.merge;
   2.284  
   2.285 -      <para id="x_1df">Notice that Mercurial does warn about the divergent
   2.286 -	renames, but it leaves it up to you to do something about the
   2.287 +      <para id="x_1df">Notice that while Mercurial warns about the divergent
   2.288 +	renames, it leaves it up to you to do something about the
   2.289  	divergence after the merge.</para>
   2.290 -
   2.291 -    </sect2>
   2.292 +    </sect2>
   2.293 +
   2.294      <sect2>
   2.295        <title>Convergent renames and merging</title>
   2.296  
   2.297 @@ -491,8 +502,8 @@
   2.298  	to the same <emphasis>destination</emphasis>. In this case,
   2.299  	Mercurial runs its normal merge machinery, and lets you guide
   2.300  	it to a suitable resolution.</para>
   2.301 -
   2.302 -    </sect2>
   2.303 +    </sect2>
   2.304 +
   2.305      <sect2>
   2.306        <title>Other name-related corner cases</title>
   2.307  
   2.308 @@ -507,6 +518,7 @@
   2.309  
   2.310      </sect2>
   2.311    </sect1>
   2.312 +
   2.313    <sect1>
   2.314      <title>Recovering from mistakes</title>
   2.315  
   2.316 @@ -523,7 +535,7 @@
   2.317        <command role="hg-cmd">hg revert</command> to get rid of
   2.318        erroneous changes to a file.</para>
   2.319  
   2.320 -    <para id="x_1e4">It's useful to remember that the <command role="hg-cmd">hg
   2.321 +    <para id="x_1e4">It's good to remember that the <command role="hg-cmd">hg
   2.322  	revert</command> command is useful for changes that you have
   2.323        not yet committed.  Once you've committed a change, if you
   2.324        decide it was a mistake, you can still do something about it,
   2.325 @@ -533,7 +545,133 @@
   2.326  	role="hg-cmd">hg revert</command> command, and details about
   2.327        how to deal with changes you have already committed, see <xref
   2.328  	linkend="chap:undo"/>.</para>
   2.329 -
   2.330 +  </sect1>
   2.331 +
   2.332 +  <sect1>
   2.333 +    <title>Dealing with tricky merges</title>
   2.334 +
   2.335 +    <para>In a complicated or large project, it's not unusual for a
   2.336 +      merge of two changesets to result in some headaches.  Suppose
   2.337 +      there's a big source file that's been extensively edited by each
   2.338 +      side of a merge: this is almost inevitably going to result in
   2.339 +      conflicts, some of which can take a few tries to sort
   2.340 +      out.</para>
   2.341 +
   2.342 +    <para>Let's develop a simple case of this and see how to deal with
   2.343 +      it.  We'll start off with a repository containing one file, and
   2.344 +      clone it twice.</para>
   2.345 +
   2.346 +    &interaction.ch04-resolve.init;
   2.347 +
   2.348 +    <para>In one clone, we'll modify the file in one way.</para>
   2.349 +
   2.350 +    &interaction.ch04-resolve.left;
   2.351 +
   2.352 +    <para>In another, we'll modify the file differently.</para>
   2.353 +
   2.354 +    &interaction.ch04-resolve.right;
   2.355 +
   2.356 +    <para>Next, we'll pull each set of changes into our original
   2.357 +      repo.</para>
   2.358 +
   2.359 +    &interaction.ch04-resolve.pull;
   2.360 +
   2.361 +    <para>We expect our repository to now contain two heads.</para>
   2.362 +
   2.363 +    &interaction.ch04-resolve.heads;
   2.364 +
   2.365 +    <para>Normally, if we run <command role="hg-cmd">hg
   2.366 +	merge</command> at this point, it will drop us into a GUI that
   2.367 +      will let us manually resolve the conflicting edits to
   2.368 +      <filename>myfile.txt</filename>.  However, to simplify things
   2.369 +      for presentation here, we'd like the merge to fail immediately
   2.370 +      instead.  Here's one way we can do so.</para>
   2.371 +
   2.372 +    &interaction.ch04-resolve.export;
   2.373 +
   2.374 +    <para>We've told Mercurial's merge machinery to run the command
   2.375 +      <command>false</command> (which, as we desire, fails
   2.376 +      immediately) if it detects a merge that it can't sort out
   2.377 +      automatically.</para>
   2.378 +
   2.379 +    <para>If we now fire up <command role="hg-cmd">hg
   2.380 +	merge</command>, it should grind to a halt and report a
   2.381 +	failure.</para>
   2.382 +
   2.383 +    &interaction.ch04-resolve.merge;
   2.384 +
   2.385 +    <para>Even if we don't notice that the merge failed, Mercurial
   2.386 +      will prevent us from accidentally committing the result of a
   2.387 +      failed merge.</para>
   2.388 +
   2.389 +    &interaction.ch04-resolve.cifail;
   2.390 +
   2.391 +    <para>When <command role="hg-cmd">hg commit</command> fails in
   2.392 +      this case, it suggests that we use the unfamiliar <command
   2.393 +	role="hg-cmd">hg resolve</command> command.  As usual,
   2.394 +	<command role="hg-cmd">hg help resolve</command> will print a
   2.395 +      helpful synopsis.</para>
   2.396 +
   2.397 +    <sect2>
   2.398 +      <title>File resolution states</title>
   2.399 +
   2.400 +      <para>When a merge occurs, most files will usually remain
   2.401 +	unmodified.  For each file where Mercurial has to do
   2.402 +	something, it tracks the state of the file.</para>
   2.403 +
   2.404 +      <itemizedlist>
   2.405 +	<listitem>
   2.406 +	  <para>A <emphasis>resolved</emphasis> file has been
   2.407 +	    successfully merged, either automatically by Mercurial or
   2.408 +	    manually with human intervention.</para>
   2.409 +	</listitem>
   2.410 +	<listitem>
   2.411 +	  <para>An <emphasis>unresolved</emphasis> file was not merged
   2.412 +	    successfully, and needs more attention.</para>
   2.413 +	</listitem>
   2.414 +      </itemizedlist>
   2.415 +
   2.416 +      <para>If Mercurial sees <emphasis>any</emphasis> file in the
   2.417 +	unresolved state after a merge, it considers the merge to have
   2.418 +	failed.  Fortunately, we do not need to restart the entire
   2.419 +	merge from scratch.</para>
   2.420 +
   2.421 +      <para>The <option role="hg-opt-resolve">--list</option> or
   2.422 +	<option role="hg-opt-resolve">-l</option> option to <command
   2.423 +	  role="hg-cmd">hg resolve</command> prints out the state of
   2.424 +	each merged file.</para>
   2.425 +
   2.426 +      &interaction.ch04-resolve.list;
   2.427 +
   2.428 +      <para>In the output from <command role="hg-cmd">hg
   2.429 +	  resolve</command>, a resolved file is marked with
   2.430 +	<literal>R</literal>, while an unresolved file is marked with
   2.431 +	<literal>U</literal>.  If any files are listed with
   2.432 +	<literal>U</literal>, we know that an attempt to commit the
   2.433 +	results of the merge will fail.</para>
   2.434 +    </sect2>
   2.435 +
   2.436 +    <sect2>
   2.437 +      <title>Resolving a file merge</title>
   2.438 +
   2.439 +      <para>We have several options to move a file from the unresolved
   2.440 +	into the resolved state.  By far the most common is to rerun
   2.441 +	<command role="hg-cmd">hg resolve</command>.  If we pass the
   2.442 +	names of individual files or directories, it will retry the
   2.443 +	merges of any unresolved files present in those locations. We
   2.444 +	can also pass the <option role="hg-opt-resolve">--all</option>
   2.445 +	or <option role="hg-opt-resolve">-a</option> option, which
   2.446 +	will retry the merges of <emphasis>all</emphasis> unresolved
   2.447 +	files.</para>
   2.448 +
   2.449 +      <para>Mercurial also lets us modify the resolution state of a
   2.450 +	file directly.  We can manually mark a file as resolved using
   2.451 +	the <option role="hg-opt-resolve">--mark</option> option, or
   2.452 +	as unresolved using the <option
   2.453 +	  role="hg-opt-resolve">--unmark</option> option.  This allows
   2.454 +	us to clean up a particularly messy merge by hand, and to keep
   2.455 +	track of our progress with each file as we go.</para>
   2.456 +    </sect2>
   2.457    </sect1>
   2.458  </chapter>
   2.459  

     3.1 --- a/en/ch05-collab.xml	Thu Apr 09 22:54:10 2009 -0700
     3.2 +++ b/en/ch05-collab.xml	Sun Apr 12 00:05:30 2009 -0700
     3.3 @@ -23,7 +23,7 @@
     3.4  
     3.5      <para id="x_44d">Also for human consumption, the web interface provides an
     3.6        RSS feed of the changes in a repository.  This lets you
     3.7 -      <quote>subscribe</quote> to a repository using your favourite
     3.8 +      <quote>subscribe</quote> to a repository using your favorite
     3.9        feed reader, and be automatically notified of activity in that
    3.10        repository as soon as it happens.  I find this capability much
    3.11        more convenient than the model of subscribing to a mailing list
    3.12 @@ -109,7 +109,7 @@
    3.13        <para id="x_456">As one example, many projects have a loose-knit group of
    3.14  	collaborators who rarely physically meet each other.  Some
    3.15  	groups like to overcome the isolation of working at a distance
    3.16 -	by organising occasional <quote>sprints</quote>.  In a sprint,
    3.17 +	by organizing occasional <quote>sprints</quote>.  In a sprint,
    3.18  	a number of people get together in a single location (a
    3.19  	company's conference room, a hotel meeting room, that kind of
    3.20  	place) and spend several days more or less locked in there,
    3.21 @@ -286,7 +286,7 @@
    3.22      <sect2>
    3.23        <title>The release train</title>
    3.24  
    3.25 -      <para id="x_46c">Some projects are organised on a <quote>train</quote>
    3.26 +      <para id="x_46c">Some projects are organized on a <quote>train</quote>
    3.27  	basis: a release is scheduled to happen every few months, and
    3.28  	whatever features are ready when the <quote>train</quote> is
    3.29  	ready to leave are allowed in.</para>

     4.1 --- a/en/ch11-mq.xml	Thu Apr 09 22:54:10 2009 -0700
     4.2 +++ b/en/ch11-mq.xml	Sun Apr 12 00:05:30 2009 -0700
     4.3 @@ -1143,7 +1143,7 @@
     4.4        free software or open source project, or a series that you
     4.5        intend to treat as a sequence of regular changesets when you're
     4.6        done, you can use some simple techniques to keep your work well
     4.7 -      organised.</para>
     4.8 +      organized.</para>
     4.9  
    4.10      <para id="x_434">Give your patches descriptive names.  A good name for a
    4.11        patch might be <filename>rework-device-alloc.patch</filename>,

     5.1 --- a/en/examples/auto-snippets.xml	Thu Apr 09 22:54:10 2009 -0700
     5.2 +++ b/en/examples/auto-snippets.xml	Sun Apr 12 00:05:30 2009 -0700
     5.3 @@ -51,6 +51,15 @@
     5.4  <!ENTITY interaction.branching.stable SYSTEM "results/branching.stable.lxo">
     5.5  <!ENTITY interaction.branching.tag SYSTEM "results/branching.tag.lxo">
     5.6  <!ENTITY interaction.branching.update SYSTEM "results/branching.update.lxo">
     5.7 +<!ENTITY interaction.ch04-resolve.cifail SYSTEM "results/ch04-resolve.cifail.lxo">
     5.8 +<!ENTITY interaction.ch04-resolve.export SYSTEM "results/ch04-resolve.export.lxo">
     5.9 +<!ENTITY interaction.ch04-resolve.heads SYSTEM "results/ch04-resolve.heads.lxo">
    5.10 +<!ENTITY interaction.ch04-resolve.init SYSTEM "results/ch04-resolve.init.lxo">
    5.11 +<!ENTITY interaction.ch04-resolve.left SYSTEM "results/ch04-resolve.left.lxo">
    5.12 +<!ENTITY interaction.ch04-resolve.list SYSTEM "results/ch04-resolve.list.lxo">
    5.13 +<!ENTITY interaction.ch04-resolve.merge SYSTEM "results/ch04-resolve.merge.lxo">
    5.14 +<!ENTITY interaction.ch04-resolve.pull SYSTEM "results/ch04-resolve.pull.lxo">
    5.15 +<!ENTITY interaction.ch04-resolve.right SYSTEM "results/ch04-resolve.right.lxo">
    5.16  <!ENTITY interaction.cmdref.diff-p SYSTEM "results/cmdref.diff-p.lxo">
    5.17  <!ENTITY interaction.daily.copy.after SYSTEM "results/daily.copy.after.lxo">
    5.18  <!ENTITY interaction.daily.copy.cat SYSTEM "results/daily.copy.cat.lxo">

     6.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     6.2 +++ b/en/examples/ch04/resolve	Sun Apr 12 00:05:30 2009 -0700
     6.3 @@ -0,0 +1,38 @@
     6.4 +#$ name: init
     6.5 +hg init conflict
     6.6 +cd conflict
     6.7 +echo first > myfile.txt
     6.8 +hg ci -A -m first
     6.9 +cd ..
    6.10 +hg clone conflict left
    6.11 +hg clone conflict right
    6.12 +
    6.13 +#$ name: left
    6.14 +cd left
    6.15 +echo left >> myfile.txt
    6.16 +hg ci -m left
    6.17 +
    6.18 +#$ name: right
    6.19 +cd ../right
    6.20 +echo right >> myfile.txt
    6.21 +hg ci -m right
    6.22 +
    6.23 +#$ name: pull
    6.24 +cd ../conflict
    6.25 +hg pull -u ../left
    6.26 +hg pull -u ../right
    6.27 +
    6.28 +#$ name: heads
    6.29 +hg heads
    6.30 +
    6.31 +#$ name: export
    6.32 +export HGMERGE=merge
    6.33 +
    6.34 +#$ name: merge
    6.35 +hg merge
    6.36 +
    6.37 +#$ name: cifail
    6.38 +hg commit -m 'Attempt to commit a failed merge'
    6.39 +
    6.40 +#$ name: list
    6.41 +hg resolve -l

     7.1 --- a/en/examples/rename.divergent	Thu Apr 09 22:54:10 2009 -0700
     7.2 +++ b/en/examples/rename.divergent	Sun Apr 12 00:05:30 2009 -0700
     7.3 @@ -14,7 +14,7 @@
     7.4  #$ name: rename.anne
     7.5  
     7.6  cd anne
     7.7 -hg mv foo bar
     7.8 +hg rename foo bar
     7.9  hg ci -m 'Rename foo to bar'
    7.10  
    7.11  #$ name: rename.bob

     8.1 --- a/en/examples/run-example	Thu Apr 09 22:54:10 2009 -0700
     8.2 +++ b/en/examples/run-example	Sun Apr 12 00:05:30 2009 -0700
     8.3 @@ -317,6 +317,7 @@
     8.4                              if out:
     8.5                                  ofp_basename = '%s.%s' % (self.name, out)
     8.6                                  norm = os.path.normpath(ofp_basename)
     8.7 +                                norm = norm.replace(os.sep, '-')
     8.8                                  example.entities[
     8.9                                      '<!ENTITY interaction.%s '
    8.10                                      'SYSTEM "results/%s.lxo">'
    8.11 @@ -345,7 +346,7 @@
    8.12                          ofp.write(hunk)
    8.13                          # then its output
    8.14                          ofp.write(xml_escape(output))
    8.15 -                    ps = newps
    8.16 +                        ps = newps
    8.17                  self.status('\n')
    8.18              except:
    8.19                  print >> sys.stderr, '(killed)'