1.1 --- a/en/ch01-tour-basic.xml	Tue Apr 28 23:33:11 2009 -0700
     1.2 +++ b/en/ch01-tour-basic.xml	Sun May 03 19:23:08 2009 -0700
     1.3 @@ -51,8 +51,10 @@
     1.4        <itemizedlist>
     1.5  	<listitem><para id="x_4">Ubuntu and Debian:</para>
     1.6  	  <programlisting>apt-get install mercurial</programlisting></listitem>
     1.7 -	<listitem><para id="x_5">Fedora and OpenSUSE:</para>
     1.8 +	<listitem><para id="x_5">Fedora:</para>
     1.9  	  <programlisting>yum install mercurial</programlisting></listitem>
    1.10 +	<listitem><para>OpenSUSE:</para>
    1.11 +	  <programlisting>zypper install mercurial</programlisting></listitem>
    1.12  	<listitem><para id="x_6">Gentoo:</para>
    1.13  	  <programlisting>emerge mercurial</programlisting></listitem>
    1.14        </itemizedlist>
    1.15 @@ -74,9 +76,9 @@
    1.16  
    1.17      <para id="x_e">To begin, we'll use the <command role="hg-cmd">hg
    1.18  	version</command> command to find out whether Mercurial is
    1.19 -      actually installed properly.  The actual version information
    1.20 -      that it prints isn't so important; it's whether it prints
    1.21 -      anything at all that we care about.</para>
    1.22 +      installed properly.  The actual version information that it
    1.23 +      prints isn't so important; we simply care whether the command
    1.24 +      runs and prints anything at all.</para>
    1.25  
    1.26      &interaction.tour.version;
    1.27  
    1.28 @@ -213,12 +215,11 @@
    1.29  	  followed by a hexadecimal (or <emphasis>hex</emphasis>)
    1.30  	  string.  These are <emphasis>identifiers</emphasis> for the
    1.31  	  changeset.  The hex string is a unique identifier: the same
    1.32 -	  hex string will always refer to the same changeset. The
    1.33 +	  hex string will always refer to the same changeset in every
    1.34 +	  copy of this repository. The
    1.35  	  number is shorter and easier to type than the hex string,
    1.36  	  but it isn't unique: the same number in two different clones
    1.37 -	  of a repository may identify different changesets.  Why
    1.38 -	  provide the number at all, then?  For local
    1.39 -	  convenience.</para>
    1.40 +	  of a repository may identify different changesets.</para>
    1.41        </listitem>
    1.42        <listitem><para id="x_1f"><literal>user</literal>: The identity of the
    1.43  	  person who created the changeset.  This is a free-form
    1.44 @@ -417,9 +418,9 @@
    1.45        </listitem>
    1.46      </itemizedlist>
    1.47  
    1.48 -    <para id="x_36">In the examples throughout this book, I use short options
    1.49 -      instead of long.  This just reflects my own preference, so don't
    1.50 -      read anything significant into it.</para>
    1.51 +    <para id="x_36">In the examples throughout this book, I usually
    1.52 +      use short options instead of long.  This simply reflects my own
    1.53 +      preference, so don't read anything significant into it.</para>
    1.54  
    1.55      <para id="x_37">Most commands that print output of some kind will print more
    1.56        output when passed a <option role="hg-opt-global">-v</option>
    1.57 @@ -590,19 +591,30 @@
    1.58  	<title>Creating a Mercurial configuration file</title>
    1.59  
    1.60  	<para id="x_4a">To set a user name, use your favorite editor
    1.61 -	    to create a file called <filename
    1.62 -	      role="special">.hgrc</filename> in your home directory.
    1.63 -	    Mercurial will use this file to look up your personalised
    1.64 -	    configuration settings.  The initial contents of your
    1.65 -	    <filename role="special">.hgrc</filename> should look like
    1.66 -	    this.</para>
    1.67 -
    1.68 -	<remark>Figure out what the appropriate directory is on
    1.69 -	  Windows.</remark>
    1.70 +	  to create a file called <filename
    1.71 +	    role="special">.hgrc</filename> in your home directory.
    1.72 +	  Mercurial will use this file to look up your personalised
    1.73 +	  configuration settings.  The initial contents of your
    1.74 +	  <filename role="special">.hgrc</filename> should look like
    1.75 +	  this.</para>
    1.76 +
    1.77 +	<tip>
    1.78 +	  <title><quote>Home directory</quote> on Windows</title>
    1.79 +
    1.80 +	  <para>When we refer to your home directory, on an English
    1.81 +	    language installation of Windows this will usually be a
    1.82 +	    folder named after your user name in
    1.83 +	    <filename>C:\Documents and Settings</filename>.  You can
    1.84 +	    find out the exact name of your home directory by opening
    1.85 +	    a command prompt window and running the following
    1.86 +	    command.</para>
    1.87 +
    1.88 +	  <screen><prompt>C:\></prompt> <userinput>echo %UserProfile%</userinput></screen>
    1.89 +	</tip>
    1.90  
    1.91  	<programlisting># This is a Mercurial configuration file.
    1.92  [ui]
    1.93 -username = Firstname Lastname &lt;email.address@domain.net&gt;</programlisting>
    1.94 +username = Firstname Lastname &lt;email.address@example.net&gt;</programlisting>
    1.95  
    1.96  	<para id="x_4b">The <quote><literal>[ui]</literal></quote> line begins a
    1.97  	  <emphasis>section</emphasis> of the config file, so you can
    1.98 @@ -620,38 +632,37 @@
    1.99  	<title>Choosing a user name</title>
   1.100  
   1.101  	<para id="x_4c">You can use any text you like as the value of
   1.102 -	    the <literal>username</literal> config item, since this
   1.103 -	    information is for reading by other people, but will not be
   1.104 -	    interpreted by Mercurial.  The convention that most
   1.105 -	    people follow is to use their name and email address, as
   1.106 -	    in the example above.</para>
   1.107 +	  the <literal>username</literal> config item, since this
   1.108 +	  information is for reading by other people, but will not be
   1.109 +	  interpreted by Mercurial.  The convention that most people
   1.110 +	  follow is to use their name and email address, as in the
   1.111 +	  example above.</para>
   1.112  	<note>
   1.113  	  <para id="x_4d">Mercurial's built-in web server obfuscates
   1.114 -	      email addresses, to make it more difficult for the email
   1.115 -	      harvesting tools that spammers use. This reduces the
   1.116 -	      likelihood that you'll start receiving more junk email
   1.117 -	      if you publish a Mercurial repository on the
   1.118 -	      web.</para></note>
   1.119 -
   1.120 +	    email addresses, to make it more difficult for the email
   1.121 +	    harvesting tools that spammers use. This reduces the
   1.122 +	    likelihood that you'll start receiving more junk email if
   1.123 +	    you publish a Mercurial repository on the
   1.124 +	    web.</para></note>
   1.125        </sect3>
   1.126      </sect2>
   1.127      <sect2>
   1.128        <title>Writing a commit message</title>
   1.129  
   1.130        <para id="x_4e">When we commit a change, Mercurial drops us into
   1.131 -	  a text editor, to enter a message that will describe the
   1.132 -	  modifications we've made in this changeset.  This is called
   1.133 -	  the <emphasis>commit message</emphasis>.  It will be a
   1.134 -	  record for readers of what we did and why, and it will be
   1.135 -	  printed by <command role="hg-cmd">hg log</command> after
   1.136 -	  we've finished committing.</para>
   1.137 +	a text editor, to enter a message that will describe the
   1.138 +	modifications we've made in this changeset.  This is called
   1.139 +	the <emphasis>commit message</emphasis>.  It will be a record
   1.140 +	for readers of what we did and why, and it will be printed by
   1.141 +	<command role="hg-cmd">hg log</command> after we've finished
   1.142 +	committing.</para>
   1.143  
   1.144         &interaction.tour.commit;
   1.145  
   1.146        <para id="x_4f">The editor that the <command role="hg-cmd">hg
   1.147 -	    commit</command> command drops us into will contain an
   1.148 -	  empty line or two, followed by a number of lines starting with
   1.149 -	  <quote><literal>HG:</literal></quote>.</para>
   1.150 +	  commit</command> command drops us into will contain an empty
   1.151 +	line or two, followed by a number of lines starting with
   1.152 +	<quote><literal>HG:</literal></quote>.</para>
   1.153  
   1.154      <programlisting>
   1.155  This is where I type my commit comment.
   1.156 @@ -663,20 +674,19 @@
   1.157  HG: changed hello.c</programlisting>
   1.158  
   1.159        <para id="x_50">Mercurial ignores the lines that start with
   1.160 -	  <quote><literal>HG:</literal></quote>; it uses them only to
   1.161 -	  tell us which files it's recording changes to.  Modifying or
   1.162 -	  deleting these lines has no effect.</para>
   1.163 +	<quote><literal>HG:</literal></quote>; it uses them only to
   1.164 +	tell us which files it's recording changes to.  Modifying or
   1.165 +	deleting these lines has no effect.</para>
   1.166      </sect2>
   1.167      <sect2>
   1.168        <title>Writing a good commit message</title>
   1.169  
   1.170        <para id="x_51">Since <command role="hg-cmd">hg log</command>
   1.171 -	  only prints the first line of a commit message by default,
   1.172 -	  it's best to write a commit message whose first line stands
   1.173 -	  alone.  Here's a real example of a commit message that
   1.174 -	  <emphasis>doesn't</emphasis> follow this guideline, and
   1.175 -	  hence has a summary that is not
   1.176 -	  readable.</para>
   1.177 +	only prints the first line of a commit message by default,
   1.178 +	it's best to write a commit message whose first line stands
   1.179 +	alone.  Here's a real example of a commit message that
   1.180 +	<emphasis>doesn't</emphasis> follow this guideline, and hence
   1.181 +	has a summary that is not readable.</para>
   1.182  
   1.183        <programlisting>
   1.184  changeset:   73:584af0e231be
   1.185 @@ -685,40 +695,51 @@
   1.186  summary:     include buildmeister/commondefs. Add exports.</programlisting>
   1.187  
   1.188        <para id="x_52">As far as the remainder of the contents of the
   1.189 -	  commit message are concerned, there are no hard-and-fast
   1.190 -	  rules.  Mercurial itself doesn't interpret or care about the
   1.191 -	  contents of the commit message, though your project may have
   1.192 -	  policies that dictate a certain kind of
   1.193 -	  formatting.</para>
   1.194 +	commit message are concerned, there are no hard-and-fast
   1.195 +	rules.  Mercurial itself doesn't interpret or care about the
   1.196 +	contents of the commit message, though your project may have
   1.197 +	policies that dictate a certain kind of formatting.</para>
   1.198        <para id="x_53">My personal preference is for short, but
   1.199 -	  informative, commit messages that tell me something that I
   1.200 -	  can't figure out with a quick glance at the output of
   1.201 -	  <command role="hg-cmd">hg log
   1.202 -	    --patch</command>.</para>
   1.203 -    </sect2>
   1.204 +	informative, commit messages that tell me something that I
   1.205 +	can't figure out with a quick glance at the output of <command
   1.206 +	  role="hg-cmd">hg log --patch</command>.</para>
   1.207 +      <para id="x_55">If we run the <command role="hg-cmd">hg
   1.208 +	  commit</command> command without any arguments, it records
   1.209 +	all of the changes we've made, as reported by <command
   1.210 +	  role="hg-cmd">hg status</command> and <command
   1.211 +	  role="hg-cmd">hg diff</command>.</para>
   1.212 +
   1.213 +      <note>
   1.214 +	<title>A surprise for Subversion users</title>
   1.215 +
   1.216 +	<para>Like other Mercurial commands, if we don't supply
   1.217 +	  explicit names to commit to the <command role="hg-cmd">hg
   1.218 +	    commit</command>, it will operate across a repository's
   1.219 +	  entire working directory.  Be wary of this if you're coming
   1.220 +	  from the Subversion or CVS world, since you might expect it
   1.221 +	  to operate only on the current directory that you happen to
   1.222 +	  be visiting and its subdirectories.</para>
   1.223 +      </note>
   1.224 +    </sect2>
   1.225 +
   1.226      <sect2>
   1.227        <title>Aborting a commit</title>
   1.228  
   1.229        <para id="x_54">If you decide that you don't want to commit
   1.230 -	  while in the middle of editing a commit message, simply exit
   1.231 -	  from your editor without saving the file that it's editing.
   1.232 -	  This will cause nothing to happen to either the repository
   1.233 -	  or the working directory.</para>
   1.234 -      <para id="x_55">If we run the <command role="hg-cmd">hg
   1.235 -	    commit</command> command without any arguments, it records
   1.236 -	  all of the changes we've made, as reported by <command
   1.237 -	    role="hg-cmd">hg status</command> and <command
   1.238 -	    role="hg-cmd">hg diff</command>.</para>
   1.239 -    </sect2>
   1.240 +	while in the middle of editing a commit message, simply exit
   1.241 +	from your editor without saving the file that it's editing.
   1.242 +	This will cause nothing to happen to either the repository or
   1.243 +	the working directory.</para>
   1.244 +    </sect2>
   1.245 +
   1.246      <sect2>
   1.247        <title>Admiring our new handiwork</title>
   1.248  
   1.249        <para id="x_56">Once we've finished the commit, we can use the
   1.250 -	  <command role="hg-cmd">hg tip</command> command to display
   1.251 -	  the changeset we just created.  This command produces output
   1.252 -	  that is identical to <command role="hg-cmd">hg
   1.253 -	    log</command>, but it only displays the newest revision in
   1.254 -	  the repository.</para>
   1.255 +	<command role="hg-cmd">hg tip</command> command to display the
   1.256 +	changeset we just created.  This command produces output that
   1.257 +	is identical to <command role="hg-cmd">hg log</command>, but
   1.258 +	it only displays the newest revision in the repository.</para>
   1.259  
   1.260        &interaction.tour.tip;
   1.261  
   1.262 @@ -741,57 +762,74 @@
   1.263      <title>Sharing changes</title>
   1.264  
   1.265      <para id="x_58">We mentioned earlier that repositories in
   1.266 -	Mercurial are self-contained.  This means that the changeset
   1.267 -	we just created exists only in our <filename
   1.268 -	  class="directory">my-hello</filename> repository.  Let's
   1.269 -	look at a few ways that we can propagate this change into
   1.270 -	other repositories.</para>
   1.271 +      Mercurial are self-contained.  This means that the changeset we
   1.272 +      just created exists only in our <filename
   1.273 +	class="directory">my-hello</filename> repository.  Let's look
   1.274 +      at a few ways that we can propagate this change into other
   1.275 +      repositories.</para>
   1.276  
   1.277      <sect2 id="sec:tour:pull">
   1.278        <title>Pulling changes from another repository</title>
   1.279 +
   1.280        <para id="x_59">To get started, let's clone our original
   1.281 -	  <filename class="directory">hello</filename> repository,
   1.282 -	  which does not contain the change we just committed.  We'll
   1.283 -	  call our temporary repository <filename
   1.284 -	    class="directory">hello-pull</filename>.</para>
   1.285 +	<filename class="directory">hello</filename> repository, which
   1.286 +	does not contain the change we just committed.  We'll call our
   1.287 +	temporary repository <filename
   1.288 +	  class="directory">hello-pull</filename>.</para>
   1.289  
   1.290        &interaction.tour.clone-pull;
   1.291  
   1.292        <para id="x_5a">We'll use the <command role="hg-cmd">hg
   1.293 -	    pull</command> command to bring changes from <filename
   1.294 -	    class="directory">my-hello</filename> into <filename
   1.295 -	    class="directory">hello-pull</filename>.  However, blindly
   1.296 -	  pulling unknown changes into a repository is a somewhat
   1.297 -	  scary prospect.  Mercurial provides the <command
   1.298 -	    role="hg-cmd">hg incoming</command> command to tell us
   1.299 -	  what changes the <command role="hg-cmd">hg pull</command>
   1.300 -	  command <emphasis>would</emphasis> pull into the repository,
   1.301 -	  without actually pulling the changes in.</para>
   1.302 +	  pull</command> command to bring changes from <filename
   1.303 +	  class="directory">my-hello</filename> into <filename
   1.304 +	  class="directory">hello-pull</filename>.  However, blindly
   1.305 +	pulling unknown changes into a repository is a somewhat scary
   1.306 +	prospect.  Mercurial provides the <command role="hg-cmd">hg
   1.307 +	  incoming</command> command to tell us what changes the
   1.308 +	<command role="hg-cmd">hg pull</command> command
   1.309 +	<emphasis>would</emphasis> pull into the repository, without
   1.310 +	actually pulling the changes in.</para>
   1.311  
   1.312        &interaction.tour.incoming;
   1.313  
   1.314 -      <para id="x_5b">Suppose you're pulling changes from a repository
   1.315 -      on the network somewhere. While you are looking at the <command
   1.316 -	  role="hg-cmd">hg incoming</command> output, and before you
   1.317 -	pull those changes, someone might have committed something in
   1.318 -	the remote repository. This means that it's possible to pull
   1.319 -	more changes than you saw when using <command
   1.320 -	  role="hg-cmd">hg incoming</command>.</para>
   1.321 -
   1.322        <para id="x_5c">Bringing changes into a repository is a simple
   1.323 -	  matter of running the <command role="hg-cmd">hg
   1.324 -	    pull</command> command, and telling it which repository to
   1.325 -	  pull from.</para>
   1.326 +	matter of running the <command role="hg-cmd">hg pull</command>
   1.327 +	command, and optionally telling it which repository to pull from.</para>
   1.328  
   1.329        &interaction.tour.pull;
   1.330  
   1.331 -      <para id="x_5d">As you can see
   1.332 -	  from the before-and-after output of <command
   1.333 -	    role="hg-cmd">hg tip</command>, we have successfully
   1.334 -	  pulled changes into our repository.  There remains one step
   1.335 -	  before we can see these changes in the working
   1.336 -	  directory.</para>
   1.337 -    </sect2>
   1.338 +      <para id="x_5d">As you can see from the before-and-after output
   1.339 +	of <command role="hg-cmd">hg tip</command>, we have
   1.340 +	successfully pulled changes into our repository.  However,
   1.341 +	Mercurial separates pulling changes in from updating the
   1.342 +	working directory. There remains one step before we will see
   1.343 +	the changes that we just pulled appear in the working
   1.344 +	directory.</para>
   1.345 +
   1.346 +      <tip>
   1.347 +	<title>Pulling specific changes</title>
   1.348 +
   1.349 +	<para id="x_5b">It is possible that due to the delay between
   1.350 +	  running <command role="hg-cmd">hg incoming</command> and
   1.351 +	  <command role="hg-cmd">hg pull</command>, you may not see
   1.352 +	  all changesets that will be brought from the other
   1.353 +	  repository. Suppose you're pulling changes from a repository
   1.354 +	  on the network somewhere. While you are looking at the
   1.355 +	  <command role="hg-cmd">hg incoming</command> output, and
   1.356 +	  before you pull those changes, someone might have committed
   1.357 +	  something in the remote repository. This means that it's
   1.358 +	  possible to pull more changes than you saw when using
   1.359 +	  <command role="hg-cmd">hg incoming</command>.</para>
   1.360 +
   1.361 +	<para>If you only want to pull precisely the changes that were
   1.362 +	  listed by <command role="hg-cmd">hg incoming</command>, or
   1.363 +	  you have some other reason to pull a subset of changes,
   1.364 +	  simply identify the change that you want to pull by its
   1.365 +	  changeset ID, e.g. <command>hg pull
   1.366 +	    -r7e95bb</command>.</para>
   1.367 +      </tip>
   1.368 +    </sect2>
   1.369 +
   1.370      <sect2>
   1.371        <title>Updating the working directory</title>
   1.372  
   1.373 @@ -807,20 +845,21 @@
   1.374  
   1.375        &interaction.tour.update;
   1.376  
   1.377 -      <para id="x_5f">It might seem a bit strange that <command role="hg-cmd">hg
   1.378 -	  pull</command> doesn't update the working directory
   1.379 -	automatically.  There's actually a good reason for this: you
   1.380 -	can use <command role="hg-cmd">hg update</command> to update
   1.381 -	the working directory to the state it was in at <emphasis>any
   1.382 -	  revision</emphasis> in the history of the repository.  If
   1.383 -	you had the working directory updated to an old revision&emdash;to
   1.384 -	hunt down the origin of a bug, say&emdash;and ran a <command
   1.385 -	  role="hg-cmd">hg pull</command> which automatically updated
   1.386 -	the working directory to a new revision, you might not be
   1.387 -	terribly happy.</para>
   1.388 -      <para id="x_60">However, since pull-then-update is such a common thing to
   1.389 -	do, Mercurial lets you combine the two by passing the <option
   1.390 -	  role="hg-opt-pull">-u</option> option to <command
   1.391 +      <para id="x_5f">It might seem a bit strange that <command
   1.392 +	  role="hg-cmd">hg pull</command> doesn't update the working
   1.393 +	directory automatically.  There's actually a good reason for
   1.394 +	this: you can use <command role="hg-cmd">hg update</command>
   1.395 +	to update the working directory to the state it was in at
   1.396 +	<emphasis>any revision</emphasis> in the history of the
   1.397 +	repository.  If you had the working directory updated to an
   1.398 +	old revision&emdash;to hunt down the origin of a bug,
   1.399 +	say&emdash;and ran a <command role="hg-cmd">hg pull</command>
   1.400 +	which automatically updated the working directory to a new
   1.401 +	revision, you might not be terribly happy.</para>
   1.402 +
   1.403 +      <para id="x_60">Since pull-then-update is such a common sequence
   1.404 +	of operations, Mercurial lets you combine the two by passing
   1.405 +	the <option role="hg-opt-pull">-u</option> option to <command
   1.406  	  role="hg-cmd">hg pull</command>.</para>
   1.407  
   1.408        <para id="x_61">If you look back at the output of <command
   1.409 @@ -832,25 +871,24 @@
   1.410  
   1.411        <!-- &interaction.xxx.fixme; -->
   1.412  
   1.413 -      <para id="x_62">To find out what revision the working directory is at, use
   1.414 -	the <command role="hg-cmd">hg parents</command>
   1.415 +      <para id="x_62">To find out what revision the working directory
   1.416 +	is at, use the <command role="hg-cmd">hg parents</command>
   1.417  	command.</para>
   1.418  
   1.419        &interaction.tour.parents;
   1.420  
   1.421        <para id="x_63">If you look back at <xref
   1.422 -	  linkend="fig:tour-basic:history"/>,
   1.423 -	you'll see arrows connecting each changeset.  The node that
   1.424 -	the arrow leads <emphasis>from</emphasis> in each case is a
   1.425 -	parent, and the node that the arrow leads
   1.426 -	<emphasis>to</emphasis> is its child.  The working directory
   1.427 -	has a parent in just the same way; this is the changeset that
   1.428 -	the working directory currently contains.</para>
   1.429 -
   1.430 -      <para id="x_64">To update the working directory to a particular revision,
   1.431 -
   1.432 -	give a revision number or changeset ID to the <command
   1.433 -	  role="hg-cmd">hg update</command> command.</para>
   1.434 +	  linkend="fig:tour-basic:history"/>, you'll see arrows
   1.435 +	connecting each changeset.  The node that the arrow leads
   1.436 +	<emphasis>from</emphasis> in each case is a parent, and the
   1.437 +	node that the arrow leads <emphasis>to</emphasis> is its
   1.438 +	child.  The working directory has a parent in just the same
   1.439 +	way; this is the changeset that the working directory
   1.440 +	currently contains.</para>
   1.441 +
   1.442 +      <para id="x_64">To update the working directory to a particular
   1.443 +	revision, give a revision number or changeset ID to the
   1.444 +	<command role="hg-cmd">hg update</command> command.</para>
   1.445  
   1.446        &interaction.tour.older;
   1.447  
   1.448 @@ -865,22 +903,21 @@
   1.449        <title>Pushing changes to another repository</title>
   1.450  
   1.451        <para id="x_66">Mercurial lets us push changes to another
   1.452 -	  repository, from the repository we're currently visiting.
   1.453 -	  As with the example of <command role="hg-cmd">hg
   1.454 -	    pull</command> above, we'll create a temporary repository
   1.455 -	  to push our changes into.</para>
   1.456 +	repository, from the repository we're currently visiting. As
   1.457 +	with the example of <command role="hg-cmd">hg pull</command>
   1.458 +	above, we'll create a temporary repository to push our changes
   1.459 +	into.</para>
   1.460  
   1.461        &interaction.tour.clone-push;
   1.462  
   1.463 -      <para id="x_67">The <command role="hg-cmd">hg outgoing</command> command
   1.464 -	  tells us what changes would be pushed into another
   1.465 -	  repository.</para>
   1.466 +      <para id="x_67">The <command role="hg-cmd">hg outgoing</command>
   1.467 +	command tells us what changes would be pushed into another
   1.468 +	repository.</para>
   1.469  
   1.470        &interaction.tour.outgoing;
   1.471  
   1.472 -      <para id="x_68">And the
   1.473 -	  <command role="hg-cmd">hg push</command> command does the
   1.474 -	  actual push.</para>
   1.475 +      <para id="x_68">And the <command role="hg-cmd">hg push</command>
   1.476 +	command does the actual push.</para>
   1.477  
   1.478        &interaction.tour.push;
   1.479  
   1.480 @@ -902,6 +939,38 @@
   1.481  
   1.482        &interaction.tour.push.nothing;
   1.483      </sect2>
   1.484 +
   1.485 +    <sect2>
   1.486 +      <title>Default locations</title>
   1.487 +
   1.488 +      <para>When we clone a repository, Mercurial records the location
   1.489 +	of the repository we cloned in the
   1.490 +	<filename>.hg/hgrc</filename> file of the new repository.  If
   1.491 +	we don't supply a location to <command>hg pull</command> from
   1.492 +	or <command>hg push</command> to, those commands will use this
   1.493 +	location as a default.  The <command>hg incoming</command>
   1.494 +	and <command>hg outgoing</command> commands do so too.</para>
   1.495 +
   1.496 +      <para>If you open a repository's <filename>.hg/hgrc</filename>
   1.497 +	file in a text editor, you will see contents like the
   1.498 +	following.</para>
   1.499 +
   1.500 +      <programlisting>[paths]
   1.501 +default = http://www.selenic.com/repo/hg</programlisting>
   1.502 +
   1.503 +      <para>It is possible&emdash;and often useful&emdash;to have the
   1.504 +	default location for <command>hg push</command> and
   1.505 +	<command>hg outgoing</command> be different from those for
   1.506 +	<command>hg pull</command> and <command>hg incoming</command>.
   1.507 +	We can do this by adding a <literal>default-push</literal>
   1.508 +	entry to the <literal>[paths]</literal> section of the
   1.509 +	<filename>.hg/hgrc</filename> file, as follows.</para>
   1.510 +
   1.511 +      <programlisting>[paths]
   1.512 +default = http://www.selenic.com/repo/hg
   1.513 +default-push = http://hg.example.com/hg</programlisting>
   1.514 +    </sect2>
   1.515 +
   1.516      <sect2>
   1.517        <title>Sharing changes over a network</title>
   1.518  
   1.519 @@ -913,10 +982,10 @@
   1.520  	
   1.521        &interaction.tour.outgoing.net;
   1.522  
   1.523 -      <para id="x_6c">In this example, we
   1.524 -	  can see what changes we could push to the remote repository,
   1.525 -	  but the repository is understandably not set up to let
   1.526 -	  anonymous users push to it.</para>
   1.527 +      <para id="x_6c">In this example, we can see what changes we
   1.528 +	could push to the remote repository, but the repository is
   1.529 +	understandably not set up to let anonymous users push to
   1.530 +	it.</para>
   1.531  
   1.532        &interaction.tour.push.net;
   1.533      </sect2>

     2.1 --- a/en/examples/auto-snippets.xml	Tue Apr 28 23:33:11 2009 -0700
     2.2 +++ b/en/examples/auto-snippets.xml	Sun May 03 19:23:08 2009 -0700
     2.3 @@ -69,6 +69,7 @@
     2.4  <!ENTITY interaction.ch09-hook.ws.better SYSTEM "results/ch09-hook.ws.better.lxo">
     2.5  <!ENTITY interaction.ch09-hook.ws.simple SYSTEM "results/ch09-hook.ws.simple.lxo">
     2.6  <!ENTITY interaction.ch10-multiline.go SYSTEM "results/ch10-multiline.go.lxo">
     2.7 +<!ENTITY interaction.ch10-multiline.orig.go SYSTEM "results/ch10-multiline.orig.go.lxo">
     2.8  <!ENTITY interaction.ch11-qdelete.convert SYSTEM "results/ch11-qdelete.convert.lxo">
     2.9  <!ENTITY interaction.ch11-qdelete.go SYSTEM "results/ch11-qdelete.go.lxo">
    2.10  <!ENTITY interaction.ch11-qdelete.import SYSTEM "results/ch11-qdelete.import.lxo">

     3.1 --- a/en/examples/tour	Tue Apr 28 23:33:11 2009 -0700
     3.2 +++ b/en/examples/tour	Sun May 03 19:23:08 2009 -0700
     3.3 @@ -119,6 +119,7 @@
     3.4  hg update 2
     3.5  hg parents
     3.6  hg update
     3.7 +hg parents
     3.8  
     3.9  #$ name: clone-push
    3.10