Bryan O'Sullivan avatar Bryan O'Sullivan committed 29f0f79

Update paragraph IDs

Comments (0)

Files changed (6)

en/ch01-tour-basic.xml

 
       &interaction.tour.clone;
 
-      <para>One advantage of using <command role="hg-cmd">hg
+      <para id="x_67c">One advantage of using <command role="hg-cmd">hg
 	  clone</command> is that, as we can see above, it lets us clone
 	repositories over the network.  Another is that it remembers
 	where we cloned from, which we'll find useful soon when we
 	  the text message that the creator of the changeset entered
 	  to describe the changeset.</para></listitem>
       <listitem>
-	<para>Some changesets, such as the first in the list above,
+	<para id="x_67d">Some changesets, such as the first in the list above,
 	  have a <literal>tag</literal> field.  A tag is another way
 	  to identify a changeset, by giving it an easy-to-remember
 	  name. (The tag named <literal>tip</literal> is special: it
 
       &interaction.tour.log-vp;
 
-      <para>The <option role="hg-opt-log">-p</option> option is
+      <para id="x_67e">The <option role="hg-opt-log">-p</option> option is
 	tremendously useful, so it's well worth remembering.</para>
 
     </sect2>
 	    role="hg-opt-log">--rev</option> arguments.</para>
       </listitem>
       <listitem>
-	<para>If you are using short options, you can save typing by
+	<para id="x_67f">If you are using short options, you can save typing by
 	  running them together. For example, the command <command
 	    role="hg-cmd">hg log -v -p -r 2</command> can be written
 	  as <command role="hg-cmd">hg log -vpr2</command>.</para>
     <note>
       <title>Option naming consistency</title>
 
-      <para>Almost always, Mercurial commands use consistent option
+      <para id="x_680">Almost always, Mercurial commands use consistent option
 	names to refer to the same concepts.  For instance, if a
 	command deals with changesets, you'll always identify them
 	with <option role="hg-opt-log">--rev</option> or <option
       locally, we can just clone that instead.  This is much faster
       than cloning over the network, and cloning a local repository
       uses less disk space in most cases, too<footnote>
-	<para>The saving of space arises when source and destination
+	<para id="x_681">The saving of space arises when source and destination
 	  repositories are on the same filesystem, in which case
 	  Mercurial will use hardlinks to do copy-on-write sharing of
 	  its internal metadata.  If that explanation meant nothing to
 
     &interaction.tour.cat1;
 
-    <para>Let's edit this file so that it prints a second line of
+    <para id="x_682">Let's edit this file so that it prints a second line of
       output.</para>
 
     &interaction.tour.cat2;
     <tip>
       <title>Understanding patches</title>
 
-      <para>Remember to take a look at <xref
+      <para id="x_683">Remember to take a look at <xref
 	  linkend="sec:mq:patch"/> if you don't know how to read
 	output above.</para>
     </tip>
 	repository as the <emphasis>tip revision</emphasis>, or simply
 	the <emphasis>tip</emphasis>.</para>
 
-      <para>By the way, the <command role="hg-cmd">hg tip</command>
+      <para id="x_684">By the way, the <command role="hg-cmd">hg tip</command>
 	command accepts many of the same options as <command
 	  role="hg-cmd">hg log</command>, so <option
 	  role="hg-opt-global">-v</option> above indicates <quote>be

en/ch02-tour-merge.xml

 	</mediaobject>
       </figure>
 
-      <para>We sometimes talk about a merge having
+      <para id="x_69c">We sometimes talk about a merge having
 	<emphasis>sides</emphasis>: the left side is the first parent
 	in the output of <command role="hg-cmd">hg parents</command>,
 	and the right side is the second.  If the working directory

en/ch03-concepts.xml

     <sect2>
       <title>Merging and renames</title>
 
-      <para>A surprising number of revision control systems pay little
+      <para id="x_69a">A surprising number of revision control systems pay little
 	or no attention to a file's <emphasis>name</emphasis> over
 	time.  For instance, it used to be common that if a file got
 	renamed on one side of a merge, the changes from the other
 	side would be silently dropped.</para>
 
-      <para>Mercurial records metadata when you tell it to perform a
+      <para id="x_69b">Mercurial records metadata when you tell it to perform a
 	rename or copy. It uses this metadata during a merge to do the
 	right thing in the case of a merge.  For instance, if I rename
 	a file, and you edit it without renaming it, when we merge our

en/ch04-daily.xml

 	<emphasis>destination</emphasis>, and all others are
 	<emphasis>sources</emphasis>.</para>
 
-      <para>If you pass <command role="hg-cmd">hg copy</command> a
+      <para id="x_685">If you pass <command role="hg-cmd">hg copy</command> a
 	single file as the source, and the destination does not exist,
 	it creates a new file with that name.</para>
 
       similar to the <command role="hg-cmd">hg copy</command>
       command.</para>
 
-    <para>If you're familiar with the Unix command line, you'll be
+    <para id="x_686">If you're familiar with the Unix command line, you'll be
       glad to know that <command role="hg-cmd">hg rename</command>
       command can be invoked as <command role="hg-cmd">hg
 	mv</command>.</para>
   <sect1>
     <title>Dealing with tricky merges</title>
 
-    <para>In a complicated or large project, it's not unusual for a
+    <para id="x_687">In a complicated or large project, it's not unusual for a
       merge of two changesets to result in some headaches.  Suppose
       there's a big source file that's been extensively edited by each
       side of a merge: this is almost inevitably going to result in
       conflicts, some of which can take a few tries to sort
       out.</para>
 
-    <para>Let's develop a simple case of this and see how to deal with
+    <para id="x_688">Let's develop a simple case of this and see how to deal with
       it.  We'll start off with a repository containing one file, and
       clone it twice.</para>
 
     &interaction.ch04-resolve.init;
 
-    <para>In one clone, we'll modify the file in one way.</para>
+    <para id="x_689">In one clone, we'll modify the file in one way.</para>
 
     &interaction.ch04-resolve.left;
 
-    <para>In another, we'll modify the file differently.</para>
+    <para id="x_68a">In another, we'll modify the file differently.</para>
 
     &interaction.ch04-resolve.right;
 
-    <para>Next, we'll pull each set of changes into our original
+    <para id="x_68b">Next, we'll pull each set of changes into our original
       repo.</para>
 
     &interaction.ch04-resolve.pull;
 
-    <para>We expect our repository to now contain two heads.</para>
+    <para id="x_68c">We expect our repository to now contain two heads.</para>
 
     &interaction.ch04-resolve.heads;
 
-    <para>Normally, if we run <command role="hg-cmd">hg
+    <para id="x_68d">Normally, if we run <command role="hg-cmd">hg
 	merge</command> at this point, it will drop us into a GUI that
       will let us manually resolve the conflicting edits to
       <filename>myfile.txt</filename>.  However, to simplify things
 
     &interaction.ch04-resolve.export;
 
-    <para>We've told Mercurial's merge machinery to run the command
+    <para id="x_68e">We've told Mercurial's merge machinery to run the command
       <command>false</command> (which, as we desire, fails
       immediately) if it detects a merge that it can't sort out
       automatically.</para>
 
-    <para>If we now fire up <command role="hg-cmd">hg
+    <para id="x_68f">If we now fire up <command role="hg-cmd">hg
 	merge</command>, it should grind to a halt and report a
 	failure.</para>
 
     &interaction.ch04-resolve.merge;
 
-    <para>Even if we don't notice that the merge failed, Mercurial
+    <para id="x_690">Even if we don't notice that the merge failed, Mercurial
       will prevent us from accidentally committing the result of a
       failed merge.</para>
 
     &interaction.ch04-resolve.cifail;
 
-    <para>When <command role="hg-cmd">hg commit</command> fails in
+    <para id="x_691">When <command role="hg-cmd">hg commit</command> fails in
       this case, it suggests that we use the unfamiliar <command
 	role="hg-cmd">hg resolve</command> command.  As usual,
 	<command role="hg-cmd">hg help resolve</command> will print a
     <sect2>
       <title>File resolution states</title>
 
-      <para>When a merge occurs, most files will usually remain
+      <para id="x_692">When a merge occurs, most files will usually remain
 	unmodified.  For each file where Mercurial has to do
 	something, it tracks the state of the file.</para>
 
       <itemizedlist>
 	<listitem>
-	  <para>A <emphasis>resolved</emphasis> file has been
+	  <para id="x_693">A <emphasis>resolved</emphasis> file has been
 	    successfully merged, either automatically by Mercurial or
 	    manually with human intervention.</para>
 	</listitem>
 	<listitem>
-	  <para>An <emphasis>unresolved</emphasis> file was not merged
+	  <para id="x_694">An <emphasis>unresolved</emphasis> file was not merged
 	    successfully, and needs more attention.</para>
 	</listitem>
       </itemizedlist>
 
-      <para>If Mercurial sees <emphasis>any</emphasis> file in the
+      <para id="x_695">If Mercurial sees <emphasis>any</emphasis> file in the
 	unresolved state after a merge, it considers the merge to have
 	failed.  Fortunately, we do not need to restart the entire
 	merge from scratch.</para>
 
-      <para>The <option role="hg-opt-resolve">--list</option> or
+      <para id="x_696">The <option role="hg-opt-resolve">--list</option> or
 	<option role="hg-opt-resolve">-l</option> option to <command
 	  role="hg-cmd">hg resolve</command> prints out the state of
 	each merged file.</para>
 
       &interaction.ch04-resolve.list;
 
-      <para>In the output from <command role="hg-cmd">hg
+      <para id="x_697">In the output from <command role="hg-cmd">hg
 	  resolve</command>, a resolved file is marked with
 	<literal>R</literal>, while an unresolved file is marked with
 	<literal>U</literal>.  If any files are listed with
     <sect2>
       <title>Resolving a file merge</title>
 
-      <para>We have several options to move a file from the unresolved
+      <para id="x_698">We have several options to move a file from the unresolved
 	into the resolved state.  By far the most common is to rerun
 	<command role="hg-cmd">hg resolve</command>.  If we pass the
 	names of individual files or directories, it will retry the
 	will retry the merges of <emphasis>all</emphasis> unresolved
 	files.</para>
 
-      <para>Mercurial also lets us modify the resolution state of a
+      <para id="x_699">Mercurial also lets us modify the resolution state of a
 	file directly.  We can manually mark a file as resolved using
 	the <option role="hg-opt-resolve">--mark</option> option, or
 	as unresolved using the <option

en/ch05-collab.xml

       to your own repositories, there are several good ways to do
       this.</para>
 
-    <para>The easiest and fastest way to get started in an informal
+    <para id="x_69d">The easiest and fastest way to get started in an informal
       environment is to use the <command role="hg-cmd">hg
 	serve</command> command, which is best suited to short-term
       <quote>lightweight</quote> serving.  See <xref
 	linkend="sec:collab:serve"/> below for details of how to use
       this command.</para>
 
-    <para>For longer-lived repositories that you'd like to have
+    <para id="x_69e">For longer-lived repositories that you'd like to have
       permanently available, there are several public hosting services
       available.</para>
 
     <itemizedlist>
       <listitem>
-	<para>Bitbucket, at <ulink
+	<para id="x_69f">Bitbucket, at <ulink
 	    url="http://bitbucket.org/">http://bitbucket.org/</ulink>,
 	  provides free hosting for open source projects, and paid
 	  hosting for commercial projects.</para>
       </listitem>
     </itemizedlist>
 
-    <para>If you would prefer to host your own repositories, Mercurial
+    <para id="x_6a0">If you would prefer to host your own repositories, Mercurial
       has built-in support for several popular hosting technologies,
       most notably CGI (Common Gateway Interface), and WSGI (Web
       Services Gateway Interface).  See <xref
     <sect2>
       <title>A hosted central repository</title>
 
-      <para>A wonderful thing about public hosting services like
+      <para id="x_6a1">A wonderful thing about public hosting services like
 	<ulink url="http://bitbucket.org/">Bitbucket</ulink> is that
 	not only do they handle the fiddly server configuration
 	details, such as user accounts, authentication, and secure
 	wire protocols, they provide additional infrastructure to make
 	this model work well.</para>
 
-      <para>For instance, a well-engineered hosting service will let
+      <para id="x_6a2">For instance, a well-engineered hosting service will let
 	people clone their own copies of a repository with a single
 	click.  This lets people work in separate spaces and share
 	their changes when they're ready.</para>
 
-      <para>In addition, a good hosting service will let people
+      <para id="x_6a3">In addition, a good hosting service will let people
 	communicate with each other, for instance to say <quote>there
 	  are changes ready for you to review in this
 	  tree</quote>.</para>
       <tip>
 	<title>Key pairs are not mandatory</title>
 
-	<para>Mercurial knows nothing about ssh authentication or key
+	<para id="x_6a4">Mercurial knows nothing about ssh authentication or key
 	  pairs.  You can, if you like, safely ignore this section and
 	  the one that follows until you grow tired of repeatedly
 	  typing ssh passwords.</para>
 
       <itemizedlist>
 	<listitem>
-	  <para>On a Unix-like system, the
+	  <para id="x_6a5">On a Unix-like system, the
 	    <command>ssh-keygen</command> command will do the
 	    trick.</para>
-	  <para>On Windows, if you're using TortoiseHg, you may need
+	  <para id="x_6a6">On Windows, if you're using TortoiseHg, you may need
 	    to download a command named <command>puttygen</command>
 	    from <ulink
 	      url="http://www.chiark.greenend.org.uk/~sgtatham/putty">the 
 	    to the agent's store.</para>
 	</listitem>
 	<listitem>
-	  <para>On Windows, if you're using TortoiseHg, the
+	  <para id="x_6a7">On Windows, if you're using TortoiseHg, the
 	    <command>pageant</command> command acts as the agent.  As
 	    with <command>puttygen</command>, you'll need to <ulink
 	      url="http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html">download 
   <sect1 id="sec:collab:cgi">
     <title>Serving over HTTP using CGI</title>
 
-    <para>The simplest way to host one or more repositories in a
+    <para id="x_6a8">The simplest way to host one or more repositories in a
       permanent way is to use a web server and Mercurial's CGI
       support.</para>
 
 	plenty of mistakes, and to spend a lot of time reading your
 	server's error logs.</para>
 
-      <para>If you don't have a strong stomach for tweaking
+      <para id="x_6a9">If you don't have a strong stomach for tweaking
 	configurations over and over, or a compelling need to host
 	your own services, you might want to try one of the public
 	hosting services that I mentioned earlier.</para>
 	    ships with several web templates.</para>
 	  <itemizedlist>
 	    <listitem>
-	      <para><literal>coal</literal> is monochromatic.</para>
+	      <para id="x_6aa"><literal>coal</literal> is monochromatic.</para>
 	    </listitem>
 	    <listitem>
-	      <para><literal>gitweb</literal> emulates the visual
+	      <para id="x_6ab"><literal>gitweb</literal> emulates the visual
 		style of git's web interface.</para>
 	    </listitem>
 	    <listitem>
-	      <para><literal>monoblue</literal> uses solid blues and
+	      <para id="x_6ac"><literal>monoblue</literal> uses solid blues and
 		greys.</para>
 	    </listitem>
 	    <listitem>
-	      <para><literal>paper</literal> is the default.</para>
+	      <para id="x_6ad"><literal>paper</literal> is the default.</para>
 	    </listitem>
 	    <listitem>
-	      <para><literal>spartan</literal> was the default for a
+	      <para id="x_6ae"><literal>spartan</literal> was the default for a
 		long time.</para>
 	    </listitem>
 	  </itemizedlist>
-	  <para>You can
+	  <para id="x_6af">You can
 	    also specify a custom template of your own; see 
 	    <xref linkend="chap:template"/> for details. Here, you can
 	    see how to enable the <literal>gitweb</literal>
   <sect1>
     <title>System-wide configuration</title>
 
-    <para>On Unix-like systems shared by multiple users (such as a
+    <para id="x_6b0">On Unix-like systems shared by multiple users (such as a
       server to which people publish changes), it often makes sense to
       set up some global default behaviors, such as what theme to use
       in web interfaces.</para>
 
-    <para>If a file named <filename>/etc/mercurial/hgrc</filename>
+    <para id="x_6b1">If a file named <filename>/etc/mercurial/hgrc</filename>
       exists, Mercurial will read it at startup time and apply any
       configuration settings it finds in that file.  It will also look
       for files ending in a <literal>.rc</literal> extension in a
     <sect2>
       <title>Making Mercurial more trusting</title>
 
-      <para>One situation in which a global <filename>hgrc</filename>
+      <para id="x_6b2">One situation in which a global <filename>hgrc</filename>
 	can be useful is if users are pulling changes owned by other
 	users.  By default, Mercurial will not trust most of the
 	configuration items in a <filename>.hg/hgrc</filename> file
 	print a warning stating that it does not trust their
 	<filename>.hg/hgrc</filename>.</para>
 
-      <para>If everyone in a particular Unix group is on the same team
+      <para id="x_6b3">If everyone in a particular Unix group is on the same team
 	and <emphasis>should</emphasis> trust each other's
 	configuration settings, or we want to trust particular users,
 	we can override Mercurial's skeptical defaults by creating a

en/ch06-filenames.xml

       directory with lock files, temporary working files, and backup
       files, which it also makes no sense to manage.</para>
 
-    <para>To have Mercurial permanently ignore such files, create a
+    <para id="x_6b4">To have Mercurial permanently ignore such files, create a
       file named <filename>.hgignore</filename> in the root of your
       repository.  You <emphasis>should</emphasis> <command>hg
       add</command> this file so that it gets tracked with the rest of
       your repository contents, since your collaborators will probably
       find it useful too.</para>
 
-    <para>By default, the <filename>.hgignore</filename> file should
+    <para id="x_6b5">By default, the <filename>.hgignore</filename> file should
       contain a list of regular expressions, one per line.  Empty
       lines are skipped. Most people prefer to describe the files they
       want to ignore using the <quote>glob</quote> syntax that we
 
     <programlisting>syntax: glob</programlisting>
 
-    <para>This tells Mercurial to interpret the lines that follow as
+    <para id="x_6b6">This tells Mercurial to interpret the lines that follow as
       glob patterns, not regular expressions.</para>
 
-    <para>Here is a typical-looking <filename>.hgignore</filename>
+    <para id="x_6b7">Here is a typical-looking <filename>.hgignore</filename>
       file.</para>
 
     <programlisting>syntax: glob
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.