1.1 --- a/en/appB-mq-ref.xml	Sun May 03 20:27:28 2009 -0700
     1.2 +++ b/en/appB-mq-ref.xml	Mon May 04 23:52:38 2009 -0700
     1.3 @@ -72,6 +72,16 @@
     1.4  
     1.5      </sect2>
     1.6      <sect2>
     1.7 +      <title><command role="hg-ext-mq">qfold</command>&emdash;move
     1.8 +	applied patches into repository history</title>
     1.9 +
    1.10 +      <para>The <command>hg qfinish</command> command converts the
    1.11 +	specified applied patches into permanent changes by moving
    1.12 +	them out of MQ's control so that they will be treated as
    1.13 +	normal repository history.</para>
    1.14 +    </sect2>
    1.15 +
    1.16 +    <sect2>
    1.17        <title><command role="hg-ext-mq">qfold</command>&emdash;merge
    1.18  	(<quote>fold</quote>) several patches into one</title>
    1.19  
    1.20 @@ -328,8 +338,8 @@
    1.21  	    no such text, a default commit message is used that
    1.22  	    identifies the name of the patch.</para>
    1.23  	</listitem></itemizedlist>
    1.24 -      <para id="x_615">If a patch contains a Mercurial patch header (XXX add
    1.25 -	link), the information in the patch header overrides these
    1.26 +      <para id="x_615">If a patch contains a Mercurial patch header,
    1.27 +	the information in the patch header overrides these
    1.28  	defaults.</para>
    1.29  
    1.30        <para id="x_616">Options:</para>
    1.31 @@ -435,21 +445,6 @@
    1.32  
    1.33      </sect2>
    1.34      <sect2>
    1.35 -      <title><command
    1.36 -	  role="hg-ext-mq">qrestore</command>&emdash;restore saved
    1.37 -	queue state</title>
    1.38 -
    1.39 -      <para id="x_628">XXX No idea what this does.</para>
    1.40 -
    1.41 -    </sect2>
    1.42 -    <sect2>
    1.43 -      <title><command role="hg-ext-mq">qsave</command>&emdash;save
    1.44 -	current queue state</title>
    1.45 -
    1.46 -      <para id="x_629">XXX Likewise.</para>
    1.47 -
    1.48 -    </sect2>
    1.49 -    <sect2>
    1.50        <title><command role="hg-ext-mq">qseries</command>&emdash;print
    1.51  	the entire patch series</title>
    1.52  
    1.53 @@ -501,9 +496,7 @@
    1.54  	    changesets in the backup bundle.</para>
    1.55  	</listitem>
    1.56  	<listitem><para id="x_631"><option role="hg-opt-strip">-f</option>: If a
    1.57 -	    branch has multiple heads, remove all heads. XXX This
    1.58 -	    should be renamed, and use <literal>-f</literal> to strip
    1.59 -	    revs when there are pending changes.</para>
    1.60 +	    branch has multiple heads, remove all heads.</para>
    1.61  	</listitem>
    1.62  	<listitem><para id="x_632"><option role="hg-opt-strip">-n</option>: Do
    1.63  	    not save a backup bundle.</para>

     2.1 --- a/en/ch02-tour-merge.xml	Sun May 03 20:27:28 2009 -0700
     2.2 +++ b/en/ch02-tour-merge.xml	Mon May 04 23:52:38 2009 -0700
     2.3 @@ -146,6 +146,7 @@
     2.4  
     2.5        &interaction.tour.merge.parents;
     2.6      </sect2>
     2.7 +
     2.8      <sect2>
     2.9        <title>Committing the results of the merge</title>
    2.10  
    2.11 @@ -292,8 +293,8 @@
    2.12  	strengths and weaknesses.  Most are tuned for merging files
    2.13  	containing plain text, while a few are aimed at specialised
    2.14  	file formats (generally XML).</para>
    2.15 -
    2.16      </sect2>
    2.17 +
    2.18      <sect2>
    2.19        <title>A worked example</title>
    2.20  
    2.21 @@ -365,6 +366,7 @@
    2.22        </note>
    2.23      </sect2>
    2.24    </sect1>
    2.25 +
    2.26    <sect1 id="sec:tour-merge:fetch">
    2.27      <title>Simplifying the pull-merge-commit sequence</title>
    2.28  
    2.29 @@ -421,7 +423,27 @@
    2.30        the extension, but since the <literal
    2.31  	role="hg-ext">fetch</literal> extension is in the standard
    2.32        distribution, Mercurial knows where to search for it.)</para>
    2.33 -
    2.34 +  </sect1>
    2.35 +
    2.36 +  <sect1>
    2.37 +    <title>Renaming, copying, and merging</title>
    2.38 +
    2.39 +    <para>During the life of a project, we will often want to change
    2.40 +      the layout of its files and directories. This can be as simple
    2.41 +      as renaming a single file, or as complex as restructuring the
    2.42 +      entire hierarchy of files within the project.</para>
    2.43 +
    2.44 +    <para>Mercurial supports these kinds of complex changes fluently,
    2.45 +      provided we tell it what we're doing.  If we want to rename a
    2.46 +      file, we should use the <command>hg rename</command><footnote>
    2.47 +	<para>If you're a Unix user, you'll be glad to know that the
    2.48 +	  <command>hg rename</command> command can be abbreviated as
    2.49 +	  <command>hg mv</command>.</para>
    2.50 +      </footnote> command to rename it, so that Mercurial can do the
    2.51 +      right thing later when we merge.</para>
    2.52 +
    2.53 +    <para>We will cover the use of these commands in more detail in
    2.54 +      <xref linkend="chap:daily.copy"/>.</para>
    2.55    </sect1>
    2.56  </chapter>
    2.57  

     3.1 --- a/en/ch03-concepts.xml	Sun May 03 20:27:28 2009 -0700
     3.2 +++ b/en/ch03-concepts.xml	Mon May 04 23:52:38 2009 -0700
     3.3 @@ -112,12 +112,15 @@
     3.4        <para id="x_2f3">As the illustration shows, there is
     3.5  	<emphasis>not</emphasis> a <quote>one to one</quote>
     3.6  	relationship between revisions in the changelog, manifest, or
     3.7 -	filelog. If the manifest hasn't changed between two
     3.8 -	changesets, the changelog entries for those changesets will
     3.9 -	point to the same revision of the manifest.  If a file that
    3.10 +	filelog. If a file that
    3.11  	Mercurial tracks hasn't changed between two changesets, the
    3.12  	entry for that file in the two revisions of the manifest will
    3.13 -	point to the same revision of its filelog.</para>
    3.14 +	point to the same revision of its filelog<footnote>
    3.15 +	  <para>It is possible (though unusual) for the manifest to
    3.16 +	    remain the same between two changesets, in which case the
    3.17 +	    changelog entries for those changesets will point to the
    3.18 +	    same revision of the manifest.</para>
    3.19 +	</footnote>.</para>
    3.20  
    3.21      </sect2>
    3.22    </sect1>
    3.23 @@ -175,16 +178,18 @@
    3.24      <sect2>
    3.25        <title>Fast retrieval</title>
    3.26  
    3.27 -      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to all earlier
    3.28 -	revision control systems: the problem of <emphasis>inefficient
    3.29 -	  retrieval</emphasis>. Most revision control systems store
    3.30 -	the contents of a revision as an incremental series of
    3.31 -	modifications against a <quote>snapshot</quote>.  To
    3.32 -	reconstruct a specific revision, you must first read the
    3.33 -	snapshot, and then every one of the revisions between the
    3.34 -	snapshot and your target revision.  The more history that a
    3.35 -	file accumulates, the more revisions you must read, hence the
    3.36 -	longer it takes to reconstruct a particular revision.</para>
    3.37 +      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to
    3.38 +	all earlier revision control systems: the problem of
    3.39 +	<emphasis>inefficient retrieval</emphasis>. Most revision
    3.40 +	control systems store the contents of a revision as an
    3.41 +	incremental series of modifications against a
    3.42 +	<quote>snapshot</quote>.  (Some base the snapshot on the
    3.43 +	oldest revision, others on the newest.)  To reconstruct a
    3.44 +	specific revision, you must first read the snapshot, and then
    3.45 +	every one of the revisions between the snapshot and your
    3.46 +	target revision.  The more history that a file accumulates,
    3.47 +	the more revisions you must read, hence the longer it takes to
    3.48 +	reconstruct a particular revision.</para>
    3.49  
    3.50        <figure id="fig:concepts:snapshot">
    3.51  	<title>Snapshot of a revlog, with incremental deltas</title>
    3.52 @@ -211,25 +216,15 @@
    3.53        <sect3>
    3.54  	<title>Aside: the influence of video compression</title>
    3.55  
    3.56 -	<para id="x_2fe">If you're familiar with video compression or have ever
    3.57 -	  watched a TV feed through a digital cable or satellite
    3.58 -	  service, you may know that most video compression schemes
    3.59 -	  store each frame of video as a delta against its predecessor
    3.60 -	  frame.  In addition, these schemes use <quote>lossy</quote>
    3.61 -	  compression techniques to increase the compression ratio, so
    3.62 -	  visual errors accumulate over the course of a number of
    3.63 -	  inter-frame deltas.</para>
    3.64 -
    3.65 -	<para id="x_2ff">Because it's possible for a video stream to <quote>drop
    3.66 -	    out</quote> occasionally due to signal glitches, and to
    3.67 -	  limit the accumulation of artefacts introduced by the lossy
    3.68 -	  compression process, video encoders periodically insert a
    3.69 -	  complete frame (called a <quote>key frame</quote>) into the
    3.70 -	  video stream; the next delta is generated against that
    3.71 -	  frame.  This means that if the video signal gets
    3.72 -	  interrupted, it will resume once the next key frame is
    3.73 -	  received.  Also, the accumulation of encoding errors
    3.74 -	  restarts anew with each key frame.</para>
    3.75 +	<para id="x_2fe">If you're familiar with video compression or
    3.76 +	  have ever watched a TV feed through a digital cable or
    3.77 +	  satellite service, you may know that most video compression
    3.78 +	  schemes store each frame of video as a delta against its
    3.79 +	  predecessor frame.</para>
    3.80 +
    3.81 +	<para id="x_2ff">Mercurial borrows this idea to make it
    3.82 +	  possible to reconstruct a revision from a snapshot and a
    3.83 +	  small number of deltas.</para>
    3.84  
    3.85        </sect3>
    3.86      </sect2>
    3.87 @@ -261,9 +256,9 @@
    3.88  	uncorrupted sections of the revlog, both before and after the
    3.89  	corrupted section.  This would not be possible with a
    3.90  	delta-only storage model.</para>
    3.91 -
    3.92      </sect2>
    3.93    </sect1>
    3.94 +
    3.95    <sect1>
    3.96      <title>Revision history, branching, and merging</title>
    3.97  
    3.98 @@ -314,11 +309,15 @@
    3.99        those files, with the same contents it had when the changeset
   3.100        was committed.</para>
   3.101  
   3.102 -    <para id="x_309">The <emphasis>dirstate</emphasis> contains Mercurial's
   3.103 -      knowledge of the working directory.  This details which
   3.104 -      changeset the working directory is updated to, and all of the
   3.105 -      files that Mercurial is tracking in the working
   3.106 -      directory.</para>
   3.107 +    <para id="x_309">The <emphasis>dirstate</emphasis> is a special
   3.108 +      structure that contains Mercurial's knowledge of the working
   3.109 +      directory.  It is maintained as a file named
   3.110 +      <filename>.hg/dirstate</filename> inside a repository.  The
   3.111 +      dirstate details which changeset the working directory is
   3.112 +      updated to, and all of the files that Mercurial is tracking in
   3.113 +      the working directory. It also lets Mercurial quickly notice
   3.114 +      changed files, by recording their checkout times and
   3.115 +      sizes.</para>
   3.116  
   3.117      <para id="x_30a">Just as a revision of a revlog has room for two parents, so
   3.118        that it can represent either a normal revision (with one parent)
   3.119 @@ -426,9 +425,9 @@
   3.120        </figure>
   3.121  
   3.122        <note>
   3.123 -	<para id="x_315">  If you're new to Mercurial, you should keep in mind a
   3.124 -	  common <quote>error</quote>, which is to use the <command
   3.125 -	    role="hg-cmd">hg pull</command> command without any
   3.126 +	<para id="x_315">If you're new to Mercurial, you should keep
   3.127 +	  in mind a common <quote>error</quote>, which is to use the
   3.128 +	  <command role="hg-cmd">hg pull</command> command without any
   3.129  	  options.  By default, the <command role="hg-cmd">hg
   3.130  	    pull</command> command <emphasis>does not</emphasis>
   3.131  	  update the working directory, so you'll bring new changesets
   3.132 @@ -436,16 +435,19 @@
   3.133  	  synced at the same changeset as before the pull.  If you
   3.134  	  make some changes and commit afterwards, you'll thus create
   3.135  	  a new head, because your working directory isn't synced to
   3.136 -	  whatever the current tip is.</para>
   3.137 -
   3.138 -	<para id="x_316">  I put the word <quote>error</quote> in
   3.139 -	  quotes because all that you need to do to rectify this
   3.140 -	  situation is <command role="hg-cmd">hg merge</command>, then
   3.141 -	  <command role="hg-cmd">hg commit</command>.  In other words,
   3.142 -	  this almost never has negative consequences; it's just
   3.143 -	  something of a surprise for newcomers.  I'll discuss other
   3.144 -	  ways to avoid this behavior, and why Mercurial behaves in
   3.145 -	  this initially surprising way, later on.</para>
   3.146 +	  whatever the current tip is.  To combine the operation of a
   3.147 +	  pull, followed by an update, run <command>hg pull
   3.148 +	    -u</command>.</para>
   3.149 +
   3.150 +	<para id="x_316">I put the word <quote>error</quote> in quotes
   3.151 +	  because all that you need to do to rectify the situation
   3.152 +	  where you created a new head by accident is
   3.153 +	  <command role="hg-cmd">hg merge</command>, then <command
   3.154 +	    role="hg-cmd">hg commit</command>.  In other words, this
   3.155 +	  almost never has negative consequences; it's just something
   3.156 +	  of a surprise for newcomers.  I'll discuss other ways to
   3.157 +	  avoid this behavior, and why Mercurial behaves in this
   3.158 +	  initially surprising way, later on.</para>
   3.159        </note>
   3.160  
   3.161      </sect2>
   3.162 @@ -511,13 +513,15 @@
   3.163  	working directory has two parents; these will become the
   3.164  	parents of the new changeset.</para>
   3.165  
   3.166 -      <para id="x_322">Mercurial lets you perform multiple merges, but you must
   3.167 -	commit the results of each individual merge as you go.  This
   3.168 -	is necessary because Mercurial only tracks two parents for
   3.169 -	both revisions and the working directory.  While it would be
   3.170 -	technically possible to merge multiple changesets at once, the
   3.171 -	prospect of user confusion and making a terrible mess of a
   3.172 -	merge immediately becomes overwhelming.</para>
   3.173 +      <para id="x_322">Mercurial lets you perform multiple merges, but
   3.174 +	you must commit the results of each individual merge as you
   3.175 +	go.  This is necessary because Mercurial only tracks two
   3.176 +	parents for both revisions and the working directory.  While
   3.177 +	it would be technically feasible to merge multiple changesets
   3.178 +	at once, Mercurial avoids this for simplicity.  With multi-way
   3.179 +	merges, the risks of user confusion, nasty conflict
   3.180 +	resolution, and making a terrible mess of a merge would grow
   3.181 +	intolerable.</para>
   3.182  
   3.183      </sect2>
   3.184  
   3.185 @@ -598,10 +602,17 @@
   3.186  	  transferred, yielding better network performance over most
   3.187  	  kinds of network.</para>
   3.188  
   3.189 -	<para id="x_329">(If the connection is over <command>ssh</command>,
   3.190 -	  Mercurial <emphasis>doesn't</emphasis> recompress the
   3.191 -	  stream, because <command>ssh</command> can already do this
   3.192 -	  itself.)</para>
   3.193 +	<para id="x_329">If the connection is over
   3.194 +	  <command>ssh</command>, Mercurial
   3.195 +	  <emphasis>doesn't</emphasis> recompress the stream, because
   3.196 +	  <command>ssh</command> can already do this itself.  You can
   3.197 +	  tell Mercurial to always use <command>ssh</command>'s
   3.198 +	  compression feature by editing the
   3.199 +	  <filename>.hgrc</filename> file in your home directory as
   3.200 +	  follows.</para>
   3.201 +
   3.202 +	<programlisting>[ui]
   3.203 +ssh = ssh -C</programlisting>
   3.204  
   3.205        </sect3>
   3.206      </sect2>
   3.207 @@ -611,9 +622,8 @@
   3.208        <para id="x_32a">Appending to files isn't the whole story when
   3.209  	it comes to guaranteeing that a reader won't see a partial
   3.210  	write.  If you recall <xref linkend="fig:concepts:metadata"/>,
   3.211 -	revisions in
   3.212 -	the changelog point to revisions in the manifest, and
   3.213 -	revisions in the manifest point to revisions in filelogs.
   3.214 +	revisions in the changelog point to revisions in the manifest,
   3.215 +	and revisions in the manifest point to revisions in filelogs.
   3.216  	This hierarchy is deliberate.</para>
   3.217  
   3.218        <para id="x_32b">A writer starts a transaction by writing filelog and
   3.219 @@ -637,7 +647,7 @@
   3.220  	being written to while the read is occurring. This has a big
   3.221  	effect on scalability; you can have an arbitrary number of
   3.222  	Mercurial processes safely reading data from a repository
   3.223 -	safely all at once, no matter whether it's being written to or
   3.224 +	all at once, no matter whether it's being written to or
   3.225  	not.</para>
   3.226  
   3.227        <para id="x_32e">The lockless nature of reading means that if you're
   3.228 @@ -709,8 +719,8 @@
   3.229  	storage is cheap, and this method gives the highest
   3.230  	performance while deferring most book-keeping to the operating
   3.231  	system.  An alternative scheme would most likely reduce
   3.232 -	performance and increase the complexity of the software, each
   3.233 -	of which is much more important to the <quote>feel</quote> of
   3.234 +	performance and increase the complexity of the software, but
   3.235 +	speed and simplicity are key to the <quote>feel</quote> of
   3.236  	day-to-day use.</para>
   3.237  
   3.238      </sect2>
   3.239 @@ -731,18 +741,32 @@
   3.240  	dirstate so that it knows what to do with those files when you
   3.241  	commit.</para>
   3.242  
   3.243 -      <para id="x_337">When Mercurial is checking the states of files in the
   3.244 -	working directory, it first checks a file's modification time.
   3.245 -	If that has not changed, the file must not have been modified.
   3.246 -	If the file's size has changed, the file must have been
   3.247 -	modified.  If the modification time has changed, but the size
   3.248 -	has not, only then does Mercurial need to read the actual
   3.249 -	contents of the file to see if they've changed. Storing these
   3.250 -	few extra pieces of information dramatically reduces the
   3.251 -	amount of data that Mercurial needs to read, which yields
   3.252 -	large performance improvements compared to other revision
   3.253 -	control systems.</para>
   3.254 -
   3.255 +      <para id="x_337">The dirstate helps Mercurial to efficiently
   3.256 +	  check the status of files in a repository.</para>
   3.257 +
   3.258 +      <itemizedlist>
   3.259 +	<listitem>
   3.260 +	  <para>When Mercurial checks the state of a file in the
   3.261 +	    working directory, it first checks a file's modification
   3.262 +	    time against the time in the dirstate that records when
   3.263 +	    Mercurial last wrote the file. If the last modified time
   3.264 +	    is the same as the time when Mercurial wrote the file, the
   3.265 +	    file must not have been modified, so Mercurial does not
   3.266 +	    need to check any further.</para>
   3.267 +	</listitem>
   3.268 +	<listitem>
   3.269 +	  <para>If the file's size has changed, the file must have
   3.270 +	    been modified.  If the modification time has changed, but
   3.271 +	    the size has not, only then does Mercurial need to
   3.272 +	    actually read the contents of the file to see if it has
   3.273 +	    changed.</para>
   3.274 +	</listitem>
   3.275 +      </itemizedlist>
   3.276 +
   3.277 +      <para>Storing the modification time and size dramatically
   3.278 +	reduces the number of read operations that Mercurial needs to
   3.279 +	perform when we run commands like <command>hg status</command>.
   3.280 +	This results in large performance improvements.</para>
   3.281      </sect2>
   3.282    </sect1>
   3.283  </chapter>

     4.1 --- a/en/ch04-daily.xml	Sun May 03 20:27:28 2009 -0700
     4.2 +++ b/en/ch04-daily.xml	Mon May 04 23:52:38 2009 -0700
     4.3 @@ -108,10 +108,11 @@
     4.4    <sect1>
     4.5      <title>How to stop tracking a file</title>
     4.6  
     4.7 -    <para id="x_1af">Once you decide that a file no longer belongs in your
     4.8 -      repository, use the <command role="hg-cmd">hg remove</command>
     4.9 -      command. This deletes the file, and tells Mercurial to stop
    4.10 -      tracking it.  A removed file is represented in the output of
    4.11 +    <para id="x_1af">Once you decide that a file no longer belongs in
    4.12 +      your repository, use the <command role="hg-cmd">hg
    4.13 +	remove</command> command. This deletes the file, and tells
    4.14 +      Mercurial to stop tracking it (which will occur at the next
    4.15 +      commit).  A removed file is represented in the output of
    4.16        <command role="hg-cmd">hg status</command> with a
    4.17        <quote><literal>R</literal></quote>.</para>
    4.18  
    4.19 @@ -214,7 +215,7 @@
    4.20      </sect2>
    4.21    </sect1>
    4.22  
    4.23 -  <sect1>
    4.24 +  <sect1 id="chap:daily.copy">
    4.25      <title>Copying files</title>
    4.26  
    4.27      <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg
    4.28 @@ -535,11 +536,12 @@
    4.29        <command role="hg-cmd">hg revert</command> to get rid of
    4.30        erroneous changes to a file.</para>
    4.31  
    4.32 -    <para id="x_1e4">It's good to remember that the <command role="hg-cmd">hg
    4.33 -	revert</command> command is useful for changes that you have
    4.34 -      not yet committed.  Once you've committed a change, if you
    4.35 -      decide it was a mistake, you can still do something about it,
    4.36 -      though your options may be more limited.</para>
    4.37 +    <para id="x_1e4">It is helpful to remember that the <command
    4.38 +	role="hg-cmd">hg revert</command> command is useful for
    4.39 +      changes that you have not yet committed.  Once you've committed
    4.40 +      a change, if you decide it was a mistake, you can still do
    4.41 +      something about it, though your options may be more
    4.42 +      limited.</para>
    4.43  
    4.44      <para id="x_1e5">For more information about the <command
    4.45  	role="hg-cmd">hg revert</command> command, and details about
    4.46 @@ -817,7 +819,7 @@
    4.47  
    4.48      <para id="x_6d9">If you perform traditional backups of your master
    4.49        repositories to tape or disk, and you want to back up a
    4.50 -      repository named <filename>myrepo</filename>.  Use <command>hg
    4.51 +      repository named <filename>myrepo</filename>, use <command>hg
    4.52  	clone -U myrepo myrepo.bak</command> to create a
    4.53        clone of <filename>myrepo</filename> before you start your
    4.54        backups.  The <option>-U</option> option doesn't check out a

     5.1 --- a/en/ch05-collab.xml	Sun May 03 20:27:28 2009 -0700
     5.2 +++ b/en/ch05-collab.xml	Mon May 04 23:52:38 2009 -0700
     5.3 @@ -55,18 +55,12 @@
     5.4  	linkend="sec:collab:serve"/> below for details of how to use
     5.5        this command.</para>
     5.6  
     5.7 -    <para id="x_69e">For longer-lived repositories that you'd like to have
     5.8 -      permanently available, there are several public hosting services
     5.9 -      available.</para>
    5.10 -
    5.11 -    <itemizedlist>
    5.12 -      <listitem>
    5.13 -	<para id="x_69f">Bitbucket, at <ulink
    5.14 -	    url="http://bitbucket.org/">http://bitbucket.org/</ulink>,
    5.15 -	  provides free hosting for open source projects, and paid
    5.16 -	  hosting for commercial projects.</para>
    5.17 -      </listitem>
    5.18 -    </itemizedlist>
    5.19 +    <para id="x_69e">For longer-lived repositories that you'd like to
    5.20 +      have permanently available, there are several public hosting
    5.21 +      services available.  Some are free to open source projects,
    5.22 +      while others offer paid commercial hosting.  An up-to-date list
    5.23 +      is available at <ulink
    5.24 +	url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
    5.25  
    5.26      <para id="x_6a0">If you would prefer to host your own repositories, Mercurial
    5.27        has built-in support for several popular hosting technologies,
    5.28 @@ -827,7 +821,7 @@
    5.29  	so that they only print output if they're run interactively.
    5.30  	Otherwise these banners will at least clutter up Mercurial's
    5.31  	output.  Worse, they could potentially cause problems with
    5.32 -	running Mercurial commands remotely.  Mercurial makes tries to
    5.33 +	running Mercurial commands remotely.  Mercurial tries to
    5.34  	detect and ignore banners in non-interactive
    5.35  	<command>ssh</command> sessions, but it is not foolproof.  (If
    5.36  	you're editing your login scripts on your server, the usual
    5.37 @@ -1107,7 +1101,7 @@
    5.38  	  directions inside it to correctly set your
    5.39  	  <envar>PYTHONPATH</envar> environment variable.</para>
    5.40  
    5.41 -	<para id="x_4cf">Finally, you are <emphasis>certain</emphasis> to by
    5.42 +	<para id="x_4cf">Finally, you are <emphasis>certain</emphasis> to be
    5.43  	  served with another colourful Python backtrace: this one
    5.44  	  will complain that it can't find <filename
    5.45  	    class="directory">/path/to/repository</filename>.  Edit

     6.1 --- a/en/ch06-filenames.xml	Sun May 03 20:27:28 2009 -0700
     6.2 +++ b/en/ch06-filenames.xml	Mon May 04 23:52:38 2009 -0700
     6.3 @@ -358,10 +358,11 @@
     6.4  	  interchangeable is also referred to as <emphasis>case
     6.5  	    folding</emphasis>.</para>
     6.6        </listitem>
     6.7 -      <listitem><para id="x_56e">Case sensitive.  The case of a name is
     6.8 -	  significant at all times. The names <filename>foo</filename>
     6.9 -	  and {FoO} identify different files.  This is the way Linux
    6.10 -	  and Unix systems normally work.</para>
    6.11 +      <listitem><para id="x_56e">Case sensitive.  The case of a name
    6.12 +	  is significant at all times. The names
    6.13 +	  <filename>foo</filename> and <filename>FoO</filename>
    6.14 +	  identify different files.  This is the way Linux and Unix
    6.15 +	  systems normally work.</para>
    6.16        </listitem></itemizedlist>
    6.17  
    6.18      <para id="x_56f">On Unix-like systems, it is possible to have any or all of

     7.1 --- a/en/ch07-branch.xml	Sun May 03 20:27:28 2009 -0700
     7.2 +++ b/en/ch07-branch.xml	Mon May 04 23:52:38 2009 -0700
     7.3 @@ -183,15 +183,15 @@
     7.4  	after the revision you specified.  This has an interaction
     7.5  	with tags that can surprise the unwary.</para>
     7.6  
     7.7 -      <para id="x_381">Recall that a tag is stored as a revision to the <filename
     7.8 -	  role="special">.hgtags</filename> file, so that when you
     7.9 -	create a tag, the changeset in which it's recorded necessarily
    7.10 -	refers to an older changeset.  When you run <command
    7.11 -	  role="hg-cmd">hg clone -r foo</command> to clone a
    7.12 -	repository as of tag <literal>foo</literal>, the new clone
    7.13 -	<emphasis>will not contain the history that created the
    7.14 -	  tag</emphasis> that you used to clone the repository.  The
    7.15 -	result is that you'll get exactly the right subset of the
    7.16 +      <para id="x_381">Recall that a tag is stored as a revision to
    7.17 +	the <filename role="special">.hgtags</filename> file. When you
    7.18 +	create a tag, the changeset in which its recorded refers to an
    7.19 +	older changeset.  When you run <command role="hg-cmd">hg clone
    7.20 +	  -r foo</command> to clone a repository as of tag
    7.21 +	<literal>foo</literal>, the new clone <emphasis>will not
    7.22 +	  contain any revision newer than the one the tag refers to,
    7.23 +	  including the revision where the tag was created</emphasis>.
    7.24 +	The result is that you'll get exactly the right subset of the
    7.25  	project's history in the new repository, but
    7.26  	<emphasis>not</emphasis> the tag you might have
    7.27  	expected.</para>
    7.28 @@ -227,9 +227,10 @@
    7.29    <sect1>
    7.30      <title>The flow of changes&emdash;big picture vs. little</title>
    7.31  
    7.32 -    <para id="x_384">To return to the outline I sketched at the beginning of a
    7.33 -      chapter, let's think about a project that has multiple
    7.34 -      concurrent pieces of work under development at once.</para>
    7.35 +    <para id="x_384">To return to the outline I sketched at the
    7.36 +      beginning of the chapter, let's think about a project that has
    7.37 +      multiple concurrent pieces of work under development at
    7.38 +      once.</para>
    7.39  
    7.40      <para id="x_385">There might be a push for a new <quote>main</quote> release;
    7.41        a new minor bugfix release to the last main release; and an
    7.42 @@ -416,7 +417,7 @@
    7.43  
    7.44      <para id="x_39e">If you have more than one named branch in a repository,
    7.45        Mercurial will remember the branch that your working directory
    7.46 -      on when you start a command like <command role="hg-cmd">hg
    7.47 +      is on when you start a command like <command role="hg-cmd">hg
    7.48  	update</command> or <command role="hg-cmd">hg pull
    7.49  	-u</command>.  It will update the working directory to the tip
    7.50        of this branch, no matter what the <quote>repo-wide</quote> tip

     8.1 --- a/en/ch09-hook.xml	Sun May 03 20:27:28 2009 -0700
     8.2 +++ b/en/ch09-hook.xml	Mon May 04 23:52:38 2009 -0700
     8.3 @@ -21,6 +21,12 @@
     8.4        supports. We will revisit each of these hooks in more detail
     8.5        later, in <xref linkend="sec:hook:ref"/>.</para>
     8.6  
     8.7 +    <para id="x_1f6">Each of the hooks whose description begins with the word
     8.8 +      <quote>Controlling</quote> has the ability to determine whether
     8.9 +      an activity can proceed.  If the hook succeeds, the activity may
    8.10 +      proceed; if it fails, the activity is either not permitted or
    8.11 +      undone, depending on the hook.</para>
    8.12 +
    8.13      <itemizedlist>
    8.14        <listitem><para id="x_1e9"><literal role="hook">changegroup</literal>: This
    8.15  	  is run after a group of changesets has been brought into the
    8.16 @@ -87,12 +93,6 @@
    8.17  	  finished.
    8.18  	</para>
    8.19        </listitem></itemizedlist>
    8.20 -    <para id="x_1f6">Each of the hooks whose description begins with the word
    8.21 -      <quote>Controlling</quote> has the ability to determine whether
    8.22 -      an activity can proceed.  If the hook succeeds, the activity may
    8.23 -      proceed; if it fails, the activity is either not permitted or
    8.24 -      undone, depending on the hook.
    8.25 -    </para>
    8.26  
    8.27    </sect1>
    8.28    <sect1>
    8.29 @@ -139,11 +139,11 @@
    8.30  	</para>
    8.31        </note>
    8.32  
    8.33 -      <para id="x_1fb">XXX To see what hooks are defined in a repository, use the
    8.34 -	<command role="hg-cmd">hg config hooks</command> command.  If
    8.35 -	you are working in one repository, but talking to another that
    8.36 -	you do not own (e.g. using <command role="hg-cmd">hg
    8.37 -	  pull</command> or <command role="hg-cmd">hg
    8.38 +      <para id="x_1fb">To see what hooks are defined in a repository,
    8.39 +	use the <command role="hg-cmd">hg showconfig hooks</command>
    8.40 +	command.  If you are working in one repository, but talking to
    8.41 +	another that you do not own (e.g. using <command
    8.42 +	  role="hg-cmd">hg pull</command> or <command role="hg-cmd">hg
    8.43  	  incoming</command>), remember that it is the other
    8.44  	repository's hooks you should be checking, not your own.
    8.45        </para>
    8.46 @@ -585,11 +585,11 @@
    8.47  
    8.48        &interaction.ch09-hook.ws.better;
    8.49  
    8.50 -      <para id="x_237">As a final aside, note in the example above the use of
    8.51 -	<command>perl</command>'s in-place editing feature to get rid
    8.52 -	of trailing whitespace from a file.  This is concise and
    8.53 -	useful enough that I will reproduce it here.
    8.54 -      </para>
    8.55 +      <para id="x_237">As a final aside, note in the example above the
    8.56 +	use of <command>sed</command>'s in-place editing feature to
    8.57 +	get rid of trailing whitespace from a file.  This is concise
    8.58 +	and useful enough that I will reproduce it here (using
    8.59 +	<command>perl</command> for good measure).</para>
    8.60        <programlisting>perl -pi -e 's,\s+$,,' filename</programlisting>
    8.61  
    8.62      </sect2>
    8.63 @@ -817,10 +817,7 @@
    8.64  		role="rc-item-bugzilla">version</envar>: The version
    8.65  	      of Bugzilla installed on the server.  The database
    8.66  	      schema that Bugzilla uses changes occasionally, so this
    8.67 -	      hook has to know exactly which schema to use. At the
    8.68 -	      moment, the only version supported is
    8.69 -	      <literal>2.16</literal>.
    8.70 -	    </para>
    8.71 +	      hook has to know exactly which schema to use.</para>
    8.72  	  </listitem>
    8.73  	  <listitem><para id="x_253"><envar role="rc-item-bugzilla">host</envar>:
    8.74  	      The hostname of the MySQL server that stores your

     9.1 --- a/en/examples/auto-snippets.xml	Sun May 03 20:27:28 2009 -0700
     9.2 +++ b/en/examples/auto-snippets.xml	Mon May 04 23:52:38 2009 -0700
     9.3 @@ -57,6 +57,15 @@
     9.4  <!ENTITY interaction.ch01-new.init SYSTEM "results/ch01-new.init.lxo">
     9.5  <!ENTITY interaction.ch01-new.ls SYSTEM "results/ch01-new.ls.lxo">
     9.6  <!ENTITY interaction.ch01-new.ls2 SYSTEM "results/ch01-new.ls2.lxo">
     9.7 +<!ENTITY interaction.ch02-rename.alice SYSTEM "results/ch02-rename.alice.lxo">
     9.8 +<!ENTITY interaction.ch02-rename.bob SYSTEM "results/ch02-rename.bob.lxo">
     9.9 +<!ENTITY interaction.ch02-rename.clone SYSTEM "results/ch02-rename.clone.lxo">
    9.10 +<!ENTITY interaction.ch02-rename.clone2 SYSTEM "results/ch02-rename.clone2.lxo">
    9.11 +<!ENTITY interaction.ch02-rename.init SYSTEM "results/ch02-rename.init.lxo">
    9.12 +<!ENTITY interaction.ch02-rename.merge SYSTEM "results/ch02-rename.merge.lxo">
    9.13 +<!ENTITY interaction.ch02-rename.merge2 SYSTEM "results/ch02-rename.merge2.lxo">
    9.14 +<!ENTITY interaction.ch02-rename.status SYSTEM "results/ch02-rename.status.lxo">
    9.15 +<!ENTITY interaction.ch02-rename.status2 SYSTEM "results/ch02-rename.status2.lxo">
    9.16  <!ENTITY interaction.ch04-diff.chmod SYSTEM "results/ch04-diff.chmod.lxo">
    9.17  <!ENTITY interaction.ch04-diff.chmod.git SYSTEM "results/ch04-diff.chmod.git.lxo">
    9.18  <!ENTITY interaction.ch04-diff.rename.basic SYSTEM "results/ch04-diff.rename.basic.lxo">
    9.19 @@ -88,6 +97,19 @@
    9.20  <!ENTITY interaction.daily.copy.dir-src-dest SYSTEM "results/daily.copy.dir-src-dest.lxo">
    9.21  <!ENTITY interaction.daily.copy.init SYSTEM "results/daily.copy.init.lxo">
    9.22  <!ENTITY interaction.daily.copy.merge SYSTEM "results/daily.copy.merge.lxo">
    9.23 +<!ENTITY interaction.daily.copy.orig.after SYSTEM "results/daily.copy.orig.after.lxo">
    9.24 +<!ENTITY interaction.daily.copy.orig.cat SYSTEM "results/daily.copy.orig.cat.lxo">
    9.25 +<!ENTITY interaction.daily.copy.orig.clone SYSTEM "results/daily.copy.orig.clone.lxo">
    9.26 +<!ENTITY interaction.daily.copy.orig.copy SYSTEM "results/daily.copy.orig.copy.lxo">
    9.27 +<!ENTITY interaction.daily.copy.orig.dir-dest SYSTEM "results/daily.copy.orig.dir-dest.lxo">
    9.28 +<!ENTITY interaction.daily.copy.orig.dir-src SYSTEM "results/daily.copy.orig.dir-src.lxo">
    9.29 +<!ENTITY interaction.daily.copy.orig.dir-src-dest SYSTEM "results/daily.copy.orig.dir-src-dest.lxo">
    9.30 +<!ENTITY interaction.daily.copy.orig.init SYSTEM "results/daily.copy.orig.init.lxo">
    9.31 +<!ENTITY interaction.daily.copy.orig.merge SYSTEM "results/daily.copy.orig.merge.lxo">
    9.32 +<!ENTITY interaction.daily.copy.orig.other SYSTEM "results/daily.copy.orig.other.lxo">
    9.33 +<!ENTITY interaction.daily.copy.orig.simple SYSTEM "results/daily.copy.orig.simple.lxo">
    9.34 +<!ENTITY interaction.daily.copy.orig.status SYSTEM "results/daily.copy.orig.status.lxo">
    9.35 +<!ENTITY interaction.daily.copy.orig.status-copy SYSTEM "results/daily.copy.orig.status-copy.lxo">
    9.36  <!ENTITY interaction.daily.copy.other SYSTEM "results/daily.copy.other.lxo">
    9.37  <!ENTITY interaction.daily.copy.simple SYSTEM "results/daily.copy.simple.lxo">
    9.38  <!ENTITY interaction.daily.copy.status SYSTEM "results/daily.copy.status.lxo">

    10.1 --- a/en/examples/daily.copy	Sun May 03 20:27:28 2009 -0700
    10.2 +++ b/en/examples/daily.copy	Mon May 04 23:52:38 2009 -0700
    10.3 @@ -51,9 +51,9 @@
    10.4  cd copy-example
    10.5  echo a > a
    10.6  echo b > b
    10.7 -mkdir c
    10.8 -mkdir c/a
    10.9 -echo c > c/a/c
   10.10 +mkdir z
   10.11 +mkdir z/a
   10.12 +echo c > z/a/c
   10.13  hg ci -Ama
   10.14  
   10.15  #$ name: simple
   10.16 @@ -70,13 +70,13 @@
   10.17  
   10.18  #$ name: dir-src
   10.19  
   10.20 -hg copy c e
   10.21 +hg copy z e
   10.22  
   10.23  #$ name: dir-src-dest
   10.24  
   10.25 -hg copy c d
   10.26 +hg copy z d
   10.27  
   10.28  #$ name: after
   10.29  
   10.30 -cp a z
   10.31 -hg copy --after a z
   10.32 +cp a n
   10.33 +hg copy --after a n

    11.1 --- a/en/examples/tour	Sun May 03 20:27:28 2009 -0700
    11.2 +++ b/en/examples/tour	Mon May 04 23:52:38 2009 -0700
    11.3 @@ -151,13 +151,18 @@
    11.4  cp hello.c ../new-hello.c
    11.5  sed -i '/printf("hello,/i\\tprintf("once more, hello.\\n");' ../new-hello.c
    11.6  
    11.7 +my-text-editor()
    11.8 +{
    11.9 +cp ../new-hello.c hello.c
   11.10 +}
   11.11 +
   11.12  #$ name: merge.clone
   11.13  
   11.14  cd ..
   11.15  hg clone hello my-new-hello
   11.16  cd my-new-hello
   11.17 -# The file new-hello.c is lightly edited.
   11.18 -cp ../new-hello.c hello.c
   11.19 +# Make some simple edits to hello.c.
   11.20 +my-text-editor hello.c
   11.21  hg commit -m 'A new hello for a new day.'
   11.22  
   11.23  #$ name: merge.dummy2