1.1 --- a/en/ch01-tour-basic.xml	Thu Apr 16 23:45:07 2009 -0700
     1.2 +++ b/en/ch01-tour-basic.xml	Thu Apr 16 23:46:45 2009 -0700
     1.3 @@ -131,7 +131,7 @@
     1.4  
     1.5        &interaction.tour.clone;
     1.6  
     1.7 -      <para>One advantage of using <command role="hg-cmd">hg
     1.8 +      <para id="x_67c">One advantage of using <command role="hg-cmd">hg
     1.9  	  clone</command> is that, as we can see above, it lets us clone
    1.10  	repositories over the network.  Another is that it remembers
    1.11  	where we cloned from, which we'll find useful soon when we
    1.12 @@ -233,7 +233,7 @@
    1.13  	  the text message that the creator of the changeset entered
    1.14  	  to describe the changeset.</para></listitem>
    1.15        <listitem>
    1.16 -	<para>Some changesets, such as the first in the list above,
    1.17 +	<para id="x_67d">Some changesets, such as the first in the list above,
    1.18  	  have a <literal>tag</literal> field.  A tag is another way
    1.19  	  to identify a changeset, by giving it an easy-to-remember
    1.20  	  name. (The tag named <literal>tip</literal> is special: it
    1.21 @@ -364,7 +364,7 @@
    1.22  
    1.23        &interaction.tour.log-vp;
    1.24  
    1.25 -      <para>The <option role="hg-opt-log">-p</option> option is
    1.26 +      <para id="x_67e">The <option role="hg-opt-log">-p</option> option is
    1.27  	tremendously useful, so it's well worth remembering.</para>
    1.28  
    1.29      </sect2>
    1.30 @@ -410,7 +410,7 @@
    1.31  	    role="hg-opt-log">--rev</option> arguments.</para>
    1.32        </listitem>
    1.33        <listitem>
    1.34 -	<para>If you are using short options, you can save typing by
    1.35 +	<para id="x_67f">If you are using short options, you can save typing by
    1.36  	  running them together. For example, the command <command
    1.37  	    role="hg-cmd">hg log -v -p -r 2</command> can be written
    1.38  	  as <command role="hg-cmd">hg log -vpr2</command>.</para>
    1.39 @@ -430,7 +430,7 @@
    1.40      <note>
    1.41        <title>Option naming consistency</title>
    1.42  
    1.43 -      <para>Almost always, Mercurial commands use consistent option
    1.44 +      <para id="x_680">Almost always, Mercurial commands use consistent option
    1.45  	names to refer to the same concepts.  For instance, if a
    1.46  	command deals with changesets, you'll always identify them
    1.47  	with <option role="hg-opt-log">--rev</option> or <option
    1.48 @@ -454,7 +454,7 @@
    1.49        locally, we can just clone that instead.  This is much faster
    1.50        than cloning over the network, and cloning a local repository
    1.51        uses less disk space in most cases, too<footnote>
    1.52 -	<para>The saving of space arises when source and destination
    1.53 +	<para id="x_681">The saving of space arises when source and destination
    1.54  	  repositories are on the same filesystem, in which case
    1.55  	  Mercurial will use hardlinks to do copy-on-write sharing of
    1.56  	  its internal metadata.  If that explanation meant nothing to
    1.57 @@ -479,7 +479,7 @@
    1.58  
    1.59      &interaction.tour.cat1;
    1.60  
    1.61 -    <para>Let's edit this file so that it prints a second line of
    1.62 +    <para id="x_682">Let's edit this file so that it prints a second line of
    1.63        output.</para>
    1.64  
    1.65      &interaction.tour.cat2;
    1.66 @@ -516,7 +516,7 @@
    1.67      <tip>
    1.68        <title>Understanding patches</title>
    1.69  
    1.70 -      <para>Remember to take a look at <xref
    1.71 +      <para id="x_683">Remember to take a look at <xref
    1.72  	  linkend="sec:mq:patch"/> if you don't know how to read
    1.73  	output above.</para>
    1.74      </tip>
    1.75 @@ -726,7 +726,7 @@
    1.76  	repository as the <emphasis>tip revision</emphasis>, or simply
    1.77  	the <emphasis>tip</emphasis>.</para>
    1.78  
    1.79 -      <para>By the way, the <command role="hg-cmd">hg tip</command>
    1.80 +      <para id="x_684">By the way, the <command role="hg-cmd">hg tip</command>
    1.81  	command accepts many of the same options as <command
    1.82  	  role="hg-cmd">hg log</command>, so <option
    1.83  	  role="hg-opt-global">-v</option> above indicates <quote>be

     2.1 --- a/en/ch02-tour-merge.xml	Thu Apr 16 23:45:07 2009 -0700
     2.2 +++ b/en/ch02-tour-merge.xml	Thu Apr 16 23:46:45 2009 -0700
     2.3 @@ -164,7 +164,7 @@
     2.4  	</mediaobject>
     2.5        </figure>
     2.6  
     2.7 -      <para>We sometimes talk about a merge having
     2.8 +      <para id="x_69c">We sometimes talk about a merge having
     2.9  	<emphasis>sides</emphasis>: the left side is the first parent
    2.10  	in the output of <command role="hg-cmd">hg parents</command>,
    2.11  	and the right side is the second.  If the working directory

     3.1 --- a/en/ch03-concepts.xml	Thu Apr 16 23:45:07 2009 -0700
     3.2 +++ b/en/ch03-concepts.xml	Thu Apr 16 23:46:45 2009 -0700
     3.3 @@ -524,13 +524,13 @@
     3.4      <sect2>
     3.5        <title>Merging and renames</title>
     3.6  
     3.7 -      <para>A surprising number of revision control systems pay little
     3.8 +      <para id="x_69a">A surprising number of revision control systems pay little
     3.9  	or no attention to a file's <emphasis>name</emphasis> over
    3.10  	time.  For instance, it used to be common that if a file got
    3.11  	renamed on one side of a merge, the changes from the other
    3.12  	side would be silently dropped.</para>
    3.13  
    3.14 -      <para>Mercurial records metadata when you tell it to perform a
    3.15 +      <para id="x_69b">Mercurial records metadata when you tell it to perform a
    3.16  	rename or copy. It uses this metadata during a merge to do the
    3.17  	right thing in the case of a merge.  For instance, if I rename
    3.18  	a file, and you edit it without renaming it, when we merge our

     4.1 --- a/en/ch04-daily.xml	Thu Apr 16 23:45:07 2009 -0700
     4.2 +++ b/en/ch04-daily.xml	Thu Apr 16 23:46:45 2009 -0700
     4.3 @@ -357,7 +357,7 @@
     4.4  	<emphasis>destination</emphasis>, and all others are
     4.5  	<emphasis>sources</emphasis>.</para>
     4.6  
     4.7 -      <para>If you pass <command role="hg-cmd">hg copy</command> a
     4.8 +      <para id="x_685">If you pass <command role="hg-cmd">hg copy</command> a
     4.9  	single file as the source, and the destination does not exist,
    4.10  	it creates a new file with that name.</para>
    4.11  
    4.12 @@ -430,7 +430,7 @@
    4.13        similar to the <command role="hg-cmd">hg copy</command>
    4.14        command.</para>
    4.15  
    4.16 -    <para>If you're familiar with the Unix command line, you'll be
    4.17 +    <para id="x_686">If you're familiar with the Unix command line, you'll be
    4.18        glad to know that <command role="hg-cmd">hg rename</command>
    4.19        command can be invoked as <command role="hg-cmd">hg
    4.20  	mv</command>.</para>
    4.21 @@ -550,37 +550,37 @@
    4.22    <sect1>
    4.23      <title>Dealing with tricky merges</title>
    4.24  
    4.25 -    <para>In a complicated or large project, it's not unusual for a
    4.26 +    <para id="x_687">In a complicated or large project, it's not unusual for a
    4.27        merge of two changesets to result in some headaches.  Suppose
    4.28        there's a big source file that's been extensively edited by each
    4.29        side of a merge: this is almost inevitably going to result in
    4.30        conflicts, some of which can take a few tries to sort
    4.31        out.</para>
    4.32  
    4.33 -    <para>Let's develop a simple case of this and see how to deal with
    4.34 +    <para id="x_688">Let's develop a simple case of this and see how to deal with
    4.35        it.  We'll start off with a repository containing one file, and
    4.36        clone it twice.</para>
    4.37  
    4.38      &interaction.ch04-resolve.init;
    4.39  
    4.40 -    <para>In one clone, we'll modify the file in one way.</para>
    4.41 +    <para id="x_689">In one clone, we'll modify the file in one way.</para>
    4.42  
    4.43      &interaction.ch04-resolve.left;
    4.44  
    4.45 -    <para>In another, we'll modify the file differently.</para>
    4.46 +    <para id="x_68a">In another, we'll modify the file differently.</para>
    4.47  
    4.48      &interaction.ch04-resolve.right;
    4.49  
    4.50 -    <para>Next, we'll pull each set of changes into our original
    4.51 +    <para id="x_68b">Next, we'll pull each set of changes into our original
    4.52        repo.</para>
    4.53  
    4.54      &interaction.ch04-resolve.pull;
    4.55  
    4.56 -    <para>We expect our repository to now contain two heads.</para>
    4.57 +    <para id="x_68c">We expect our repository to now contain two heads.</para>
    4.58  
    4.59      &interaction.ch04-resolve.heads;
    4.60  
    4.61 -    <para>Normally, if we run <command role="hg-cmd">hg
    4.62 +    <para id="x_68d">Normally, if we run <command role="hg-cmd">hg
    4.63  	merge</command> at this point, it will drop us into a GUI that
    4.64        will let us manually resolve the conflicting edits to
    4.65        <filename>myfile.txt</filename>.  However, to simplify things
    4.66 @@ -589,24 +589,24 @@
    4.67  
    4.68      &interaction.ch04-resolve.export;
    4.69  
    4.70 -    <para>We've told Mercurial's merge machinery to run the command
    4.71 +    <para id="x_68e">We've told Mercurial's merge machinery to run the command
    4.72        <command>false</command> (which, as we desire, fails
    4.73        immediately) if it detects a merge that it can't sort out
    4.74        automatically.</para>
    4.75  
    4.76 -    <para>If we now fire up <command role="hg-cmd">hg
    4.77 +    <para id="x_68f">If we now fire up <command role="hg-cmd">hg
    4.78  	merge</command>, it should grind to a halt and report a
    4.79  	failure.</para>
    4.80  
    4.81      &interaction.ch04-resolve.merge;
    4.82  
    4.83 -    <para>Even if we don't notice that the merge failed, Mercurial
    4.84 +    <para id="x_690">Even if we don't notice that the merge failed, Mercurial
    4.85        will prevent us from accidentally committing the result of a
    4.86        failed merge.</para>
    4.87  
    4.88      &interaction.ch04-resolve.cifail;
    4.89  
    4.90 -    <para>When <command role="hg-cmd">hg commit</command> fails in
    4.91 +    <para id="x_691">When <command role="hg-cmd">hg commit</command> fails in
    4.92        this case, it suggests that we use the unfamiliar <command
    4.93  	role="hg-cmd">hg resolve</command> command.  As usual,
    4.94  	<command role="hg-cmd">hg help resolve</command> will print a
    4.95 @@ -615,35 +615,35 @@
    4.96      <sect2>
    4.97        <title>File resolution states</title>
    4.98  
    4.99 -      <para>When a merge occurs, most files will usually remain
   4.100 +      <para id="x_692">When a merge occurs, most files will usually remain
   4.101  	unmodified.  For each file where Mercurial has to do
   4.102  	something, it tracks the state of the file.</para>
   4.103  
   4.104        <itemizedlist>
   4.105  	<listitem>
   4.106 -	  <para>A <emphasis>resolved</emphasis> file has been
   4.107 +	  <para id="x_693">A <emphasis>resolved</emphasis> file has been
   4.108  	    successfully merged, either automatically by Mercurial or
   4.109  	    manually with human intervention.</para>
   4.110  	</listitem>
   4.111  	<listitem>
   4.112 -	  <para>An <emphasis>unresolved</emphasis> file was not merged
   4.113 +	  <para id="x_694">An <emphasis>unresolved</emphasis> file was not merged
   4.114  	    successfully, and needs more attention.</para>
   4.115  	</listitem>
   4.116        </itemizedlist>
   4.117  
   4.118 -      <para>If Mercurial sees <emphasis>any</emphasis> file in the
   4.119 +      <para id="x_695">If Mercurial sees <emphasis>any</emphasis> file in the
   4.120  	unresolved state after a merge, it considers the merge to have
   4.121  	failed.  Fortunately, we do not need to restart the entire
   4.122  	merge from scratch.</para>
   4.123  
   4.124 -      <para>The <option role="hg-opt-resolve">--list</option> or
   4.125 +      <para id="x_696">The <option role="hg-opt-resolve">--list</option> or
   4.126  	<option role="hg-opt-resolve">-l</option> option to <command
   4.127  	  role="hg-cmd">hg resolve</command> prints out the state of
   4.128  	each merged file.</para>
   4.129  
   4.130        &interaction.ch04-resolve.list;
   4.131  
   4.132 -      <para>In the output from <command role="hg-cmd">hg
   4.133 +      <para id="x_697">In the output from <command role="hg-cmd">hg
   4.134  	  resolve</command>, a resolved file is marked with
   4.135  	<literal>R</literal>, while an unresolved file is marked with
   4.136  	<literal>U</literal>.  If any files are listed with
   4.137 @@ -654,7 +654,7 @@
   4.138      <sect2>
   4.139        <title>Resolving a file merge</title>
   4.140  
   4.141 -      <para>We have several options to move a file from the unresolved
   4.142 +      <para id="x_698">We have several options to move a file from the unresolved
   4.143  	into the resolved state.  By far the most common is to rerun
   4.144  	<command role="hg-cmd">hg resolve</command>.  If we pass the
   4.145  	names of individual files or directories, it will retry the
   4.146 @@ -664,7 +664,7 @@
   4.147  	will retry the merges of <emphasis>all</emphasis> unresolved
   4.148  	files.</para>
   4.149  
   4.150 -      <para>Mercurial also lets us modify the resolution state of a
   4.151 +      <para id="x_699">Mercurial also lets us modify the resolution state of a
   4.152  	file directly.  We can manually mark a file as resolved using
   4.153  	the <option role="hg-opt-resolve">--mark</option> option, or
   4.154  	as unresolved using the <option

     5.1 --- a/en/ch05-collab.xml	Thu Apr 16 23:45:07 2009 -0700
     5.2 +++ b/en/ch05-collab.xml	Thu Apr 16 23:46:45 2009 -0700
     5.3 @@ -48,27 +48,27 @@
     5.4        to your own repositories, there are several good ways to do
     5.5        this.</para>
     5.6  
     5.7 -    <para>The easiest and fastest way to get started in an informal
     5.8 +    <para id="x_69d">The easiest and fastest way to get started in an informal
     5.9        environment is to use the <command role="hg-cmd">hg
    5.10  	serve</command> command, which is best suited to short-term
    5.11        <quote>lightweight</quote> serving.  See <xref
    5.12  	linkend="sec:collab:serve"/> below for details of how to use
    5.13        this command.</para>
    5.14  
    5.15 -    <para>For longer-lived repositories that you'd like to have
    5.16 +    <para id="x_69e">For longer-lived repositories that you'd like to have
    5.17        permanently available, there are several public hosting services
    5.18        available.</para>
    5.19  
    5.20      <itemizedlist>
    5.21        <listitem>
    5.22 -	<para>Bitbucket, at <ulink
    5.23 +	<para id="x_69f">Bitbucket, at <ulink
    5.24  	    url="http://bitbucket.org/">http://bitbucket.org/</ulink>,
    5.25  	  provides free hosting for open source projects, and paid
    5.26  	  hosting for commercial projects.</para>
    5.27        </listitem>
    5.28      </itemizedlist>
    5.29  
    5.30 -    <para>If you would prefer to host your own repositories, Mercurial
    5.31 +    <para id="x_6a0">If you would prefer to host your own repositories, Mercurial
    5.32        has built-in support for several popular hosting technologies,
    5.33        most notably CGI (Common Gateway Interface), and WSGI (Web
    5.34        Services Gateway Interface).  See <xref
    5.35 @@ -198,19 +198,19 @@
    5.36      <sect2>
    5.37        <title>A hosted central repository</title>
    5.38  
    5.39 -      <para>A wonderful thing about public hosting services like
    5.40 +      <para id="x_6a1">A wonderful thing about public hosting services like
    5.41  	<ulink url="http://bitbucket.org/">Bitbucket</ulink> is that
    5.42  	not only do they handle the fiddly server configuration
    5.43  	details, such as user accounts, authentication, and secure
    5.44  	wire protocols, they provide additional infrastructure to make
    5.45  	this model work well.</para>
    5.46  
    5.47 -      <para>For instance, a well-engineered hosting service will let
    5.48 +      <para id="x_6a2">For instance, a well-engineered hosting service will let
    5.49  	people clone their own copies of a repository with a single
    5.50  	click.  This lets people work in separate spaces and share
    5.51  	their changes when they're ready.</para>
    5.52  
    5.53 -      <para>In addition, a good hosting service will let people
    5.54 +      <para id="x_6a3">In addition, a good hosting service will let people
    5.55  	communicate with each other, for instance to say <quote>there
    5.56  	  are changes ready for you to review in this
    5.57  	  tree</quote>.</para>
    5.58 @@ -643,7 +643,7 @@
    5.59        <tip>
    5.60  	<title>Key pairs are not mandatory</title>
    5.61  
    5.62 -	<para>Mercurial knows nothing about ssh authentication or key
    5.63 +	<para id="x_6a4">Mercurial knows nothing about ssh authentication or key
    5.64  	  pairs.  You can, if you like, safely ignore this section and
    5.65  	  the one that follows until you grow tired of repeatedly
    5.66  	  typing ssh passwords.</para>
    5.67 @@ -651,10 +651,10 @@
    5.68  
    5.69        <itemizedlist>
    5.70  	<listitem>
    5.71 -	  <para>On a Unix-like system, the
    5.72 +	  <para id="x_6a5">On a Unix-like system, the
    5.73  	    <command>ssh-keygen</command> command will do the
    5.74  	    trick.</para>
    5.75 -	  <para>On Windows, if you're using TortoiseHg, you may need
    5.76 +	  <para id="x_6a6">On Windows, if you're using TortoiseHg, you may need
    5.77  	    to download a command named <command>puttygen</command>
    5.78  	    from <ulink
    5.79  	      url="http://www.chiark.greenend.org.uk/~sgtatham/putty">the 
    5.80 @@ -716,7 +716,7 @@
    5.81  	    to the agent's store.</para>
    5.82  	</listitem>
    5.83  	<listitem>
    5.84 -	  <para>On Windows, if you're using TortoiseHg, the
    5.85 +	  <para id="x_6a7">On Windows, if you're using TortoiseHg, the
    5.86  	    <command>pageant</command> command acts as the agent.  As
    5.87  	    with <command>puttygen</command>, you'll need to <ulink
    5.88  	      url="http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html">download 
    5.89 @@ -928,7 +928,7 @@
    5.90    <sect1 id="sec:collab:cgi">
    5.91      <title>Serving over HTTP using CGI</title>
    5.92  
    5.93 -    <para>The simplest way to host one or more repositories in a
    5.94 +    <para id="x_6a8">The simplest way to host one or more repositories in a
    5.95        permanent way is to use a web server and Mercurial's CGI
    5.96        support.</para>
    5.97  
    5.98 @@ -952,7 +952,7 @@
    5.99  	plenty of mistakes, and to spend a lot of time reading your
   5.100  	server's error logs.</para>
   5.101  
   5.102 -      <para>If you don't have a strong stomach for tweaking
   5.103 +      <para id="x_6a9">If you don't have a strong stomach for tweaking
   5.104  	configurations over and over, or a compelling need to host
   5.105  	your own services, you might want to try one of the public
   5.106  	hosting services that I mentioned earlier.</para>
   5.107 @@ -1394,25 +1394,25 @@
   5.108  	    ships with several web templates.</para>
   5.109  	  <itemizedlist>
   5.110  	    <listitem>
   5.111 -	      <para><literal>coal</literal> is monochromatic.</para>
   5.112 +	      <para id="x_6aa"><literal>coal</literal> is monochromatic.</para>
   5.113  	    </listitem>
   5.114  	    <listitem>
   5.115 -	      <para><literal>gitweb</literal> emulates the visual
   5.116 +	      <para id="x_6ab"><literal>gitweb</literal> emulates the visual
   5.117  		style of git's web interface.</para>
   5.118  	    </listitem>
   5.119  	    <listitem>
   5.120 -	      <para><literal>monoblue</literal> uses solid blues and
   5.121 +	      <para id="x_6ac"><literal>monoblue</literal> uses solid blues and
   5.122  		greys.</para>
   5.123  	    </listitem>
   5.124  	    <listitem>
   5.125 -	      <para><literal>paper</literal> is the default.</para>
   5.126 +	      <para id="x_6ad"><literal>paper</literal> is the default.</para>
   5.127  	    </listitem>
   5.128  	    <listitem>
   5.129 -	      <para><literal>spartan</literal> was the default for a
   5.130 +	      <para id="x_6ae"><literal>spartan</literal> was the default for a
   5.131  		long time.</para>
   5.132  	    </listitem>
   5.133  	  </itemizedlist>
   5.134 -	  <para>You can
   5.135 +	  <para id="x_6af">You can
   5.136  	    also specify a custom template of your own; see 
   5.137  	    <xref linkend="chap:template"/> for details. Here, you can
   5.138  	    see how to enable the <literal>gitweb</literal>
   5.139 @@ -1523,12 +1523,12 @@
   5.140    <sect1>
   5.141      <title>System-wide configuration</title>
   5.142  
   5.143 -    <para>On Unix-like systems shared by multiple users (such as a
   5.144 +    <para id="x_6b0">On Unix-like systems shared by multiple users (such as a
   5.145        server to which people publish changes), it often makes sense to
   5.146        set up some global default behaviors, such as what theme to use
   5.147        in web interfaces.</para>
   5.148  
   5.149 -    <para>If a file named <filename>/etc/mercurial/hgrc</filename>
   5.150 +    <para id="x_6b1">If a file named <filename>/etc/mercurial/hgrc</filename>
   5.151        exists, Mercurial will read it at startup time and apply any
   5.152        configuration settings it finds in that file.  It will also look
   5.153        for files ending in a <literal>.rc</literal> extension in a
   5.154 @@ -1539,7 +1539,7 @@
   5.155      <sect2>
   5.156        <title>Making Mercurial more trusting</title>
   5.157  
   5.158 -      <para>One situation in which a global <filename>hgrc</filename>
   5.159 +      <para id="x_6b2">One situation in which a global <filename>hgrc</filename>
   5.160  	can be useful is if users are pulling changes owned by other
   5.161  	users.  By default, Mercurial will not trust most of the
   5.162  	configuration items in a <filename>.hg/hgrc</filename> file
   5.163 @@ -1548,7 +1548,7 @@
   5.164  	print a warning stating that it does not trust their
   5.165  	<filename>.hg/hgrc</filename>.</para>
   5.166  
   5.167 -      <para>If everyone in a particular Unix group is on the same team
   5.168 +      <para id="x_6b3">If everyone in a particular Unix group is on the same team
   5.169  	and <emphasis>should</emphasis> trust each other's
   5.170  	configuration settings, or we want to trust particular users,
   5.171  	we can override Mercurial's skeptical defaults by creating a

     6.1 --- a/en/ch06-filenames.xml	Thu Apr 16 23:45:07 2009 -0700
     6.2 +++ b/en/ch06-filenames.xml	Thu Apr 16 23:46:45 2009 -0700
     6.3 @@ -283,14 +283,14 @@
     6.4        directory with lock files, temporary working files, and backup
     6.5        files, which it also makes no sense to manage.</para>
     6.6  
     6.7 -    <para>To have Mercurial permanently ignore such files, create a
     6.8 +    <para id="x_6b4">To have Mercurial permanently ignore such files, create a
     6.9        file named <filename>.hgignore</filename> in the root of your
    6.10        repository.  You <emphasis>should</emphasis> <command>hg
    6.11        add</command> this file so that it gets tracked with the rest of
    6.12        your repository contents, since your collaborators will probably
    6.13        find it useful too.</para>
    6.14  
    6.15 -    <para>By default, the <filename>.hgignore</filename> file should
    6.16 +    <para id="x_6b5">By default, the <filename>.hgignore</filename> file should
    6.17        contain a list of regular expressions, one per line.  Empty
    6.18        lines are skipped. Most people prefer to describe the files they
    6.19        want to ignore using the <quote>glob</quote> syntax that we
    6.20 @@ -299,10 +299,10 @@
    6.21  
    6.22      <programlisting>syntax: glob</programlisting>
    6.23  
    6.24 -    <para>This tells Mercurial to interpret the lines that follow as
    6.25 +    <para id="x_6b6">This tells Mercurial to interpret the lines that follow as
    6.26        glob patterns, not regular expressions.</para>
    6.27  
    6.28 -    <para>Here is a typical-looking <filename>.hgignore</filename>
    6.29 +    <para id="x_6b7">Here is a typical-looking <filename>.hgignore</filename>
    6.30        file.</para>
    6.31  
    6.32      <programlisting>syntax: glob