1.1 --- a/en/ch08-undo.xml	Tue Apr 21 23:49:27 2009 -0700
     1.2 +++ b/en/ch08-undo.xml	Tue Apr 21 23:51:47 2009 -0700
     1.3 @@ -196,7 +196,7 @@
     1.4      <tip>
     1.5        <title>Be careful with <filename>.orig</filename> files</title>
     1.6  
     1.7 -      <para>It's extremely unlikely that you are either using
     1.8 +      <para id="x_6b8">It's extremely unlikely that you are either using
     1.9  	Mercurial to manage files with <filename>.orig</filename>
    1.10  	extensions or that you even care about the contents of such
    1.11  	files.  Just in case, though, it's useful to remember that
    1.12 @@ -396,7 +396,7 @@
    1.13  	  were</quote>, only with some extra history that undoes the
    1.14  	effect of the changeset you wanted to back out.</para>
    1.15  
    1.16 -      <para>You might wonder why Mercurial does not commit the result
    1.17 +      <para id="x_6b9">You might wonder why Mercurial does not commit the result
    1.18  	of the merge that it performed.  The reason lies in Mercurial
    1.19  	behaving conservatively: a merge naturally has more scope for
    1.20  	error than simply undoing the effect of the tip changeset,
    1.21 @@ -634,14 +634,14 @@
    1.22      <sect2>
    1.23        <title>Backing out a merge</title>
    1.24  
    1.25 -      <para>Since merges are often complicated, it is not unheard of
    1.26 +      <para id="x_6ba">Since merges are often complicated, it is not unheard of
    1.27  	for a merge to be mangled badly, but committed erroneously.
    1.28  	Mercurial provides an important safeguard against bad merges
    1.29  	by refusing to commit unresolved files, but human ingenuity
    1.30  	guarantees that it is still possible to mess a merge up and
    1.31  	commit it.</para>
    1.32  
    1.33 -      <para>Given a bad merge that has been committed, usually the
    1.34 +      <para id="x_6bb">Given a bad merge that has been committed, usually the
    1.35  	best way to approach it is to simply try to repair the damage
    1.36  	by hand.  A complete disaster that cannot be easily fixed up
    1.37  	by hand ought to be very rare, but the <command
    1.38 @@ -659,16 +659,16 @@
    1.39  	</mediaobject>
    1.40        </figure>
    1.41  
    1.42 -      <para>Suppose we have a revision graph like that in <xref
    1.43 +      <para id="x_6bc">Suppose we have a revision graph like that in <xref
    1.44  	  linkend="fig:undo:bad-merge-1"/>.  What we'd like is to
    1.45  	<emphasis>redo</emphasis> the merge of revisions 2 and
    1.46  	3.</para>
    1.47  
    1.48 -      <para>One way to do so would be as follows.</para>
    1.49 +      <para id="x_6bd">One way to do so would be as follows.</para>
    1.50  
    1.51        <orderedlist>
    1.52  	<listitem>
    1.53 -	  <para>Call <command role="hg-cmd">hg backout --rev=4
    1.54 +	  <para id="x_6be">Call <command role="hg-cmd">hg backout --rev=4
    1.55  	      --parent=2</command>.  This tells <command
    1.56  	      role="hg-cmd">hg backout</command> to back out revision
    1.57  	    4, which is the bad merge, and to when deciding which
    1.58 @@ -685,7 +685,7 @@
    1.59  	</listitem>
    1.60  
    1.61  	<listitem>
    1.62 -	  <para>Call <command role="hg-cmd">hg backout --rev=4
    1.63 +	  <para id="x_6bf">Call <command role="hg-cmd">hg backout --rev=4
    1.64  	      --parent=3</command>.  This tells <command
    1.65  	      role="hg-cmd">hg backout</command> to back out revision
    1.66  	    4 again, but this time to choose parent 3, the other
    1.67 @@ -703,7 +703,7 @@
    1.68  	</listitem>
    1.69  
    1.70  	<listitem>
    1.71 -	  <para>Redo the bad merge by merging the two backout heads,
    1.72 +	  <para id="x_6c0">Redo the bad merge by merging the two backout heads,
    1.73  	    which reduces the number of heads in the repository to
    1.74  	    two, as can be seen in <xref
    1.75  	      linkend="fig:undo:bad-merge-4"/>.</para>
    1.76 @@ -717,7 +717,7 @@
    1.77  	</listitem>
    1.78  
    1.79  	<listitem>
    1.80 -	  <para>Merge with the commit that was made after the bad
    1.81 +	  <para id="x_6c1">Merge with the commit that was made after the bad
    1.82  	    merge, as shown in <xref
    1.83  	      linkend="fig:undo:bad-merge-5"/>.</para>
    1.84  	  <figure id="fig:undo:bad-merge-5">
    1.85 @@ -761,11 +761,11 @@
    1.86      <sect2>
    1.87        <title>What to do about sensitive changes that escape</title>
    1.88  
    1.89 -      <para>Even a carefully run project can suffer an unfortunate
    1.90 +      <para id="x_6c2">Even a carefully run project can suffer an unfortunate
    1.91  	event such as the committing and uncontrolled propagation of a
    1.92  	file that contains important passwords.</para>
    1.93  
    1.94 -      <para>If something like this happens to you, and the information
    1.95 +      <para id="x_6c3">If something like this happens to you, and the information
    1.96  	that gets accidentally propagated is truly sensitive, your
    1.97  	first step should be to mitigate the effect of the leak
    1.98  	without trying to control the leak itself. If you are not 100%
    1.99 @@ -776,12 +776,12 @@
   1.100  	the change has propagated far and wide, and that there's
   1.101  	nothing more you can do.</para>
   1.102  
   1.103 -      <para>You might hope that there would be mechanisms you could
   1.104 +      <para id="x_6c4">You might hope that there would be mechanisms you could
   1.105  	use to either figure out who has seen a change or to erase the
   1.106  	change permanently everywhere, but there are good reasons why
   1.107  	these are not possible.</para>
   1.108  
   1.109 -      <para>Mercurial does not provide an audit trail of who has
   1.110 +      <para id="x_6c5">Mercurial does not provide an audit trail of who has
   1.111  	pulled changes from a repository, because it is usually either
   1.112  	impossible to record such information or trivial to spoof it.
   1.113  	In a multi-user or networked environment, you should thus be
   1.114 @@ -793,7 +793,7 @@
   1.115  	completely innocent ways to confound your attempts to track
   1.116  	down every copy of a problematic change.</para>
   1.117  
   1.118 -      <para>Mercurial also does not provide a way to make a file or
   1.119 +      <para id="x_6c6">Mercurial also does not provide a way to make a file or
   1.120  	changeset completely disappear from history, because there is
   1.121  	no way to enforce its disappearance; someone could easily
   1.122  	modify their copy of Mercurial to ignore such directives. In