# HG changeset patch
# User Bryan O'Sullivan <bos@serpentine.com>
# Date 1241506358 25200
# Node ID 477d6a3e50232c27a6dff70a392cff37d09d6017
# Parent  d2aacc06e562b175c4b1f8ac1d226255630d4bc4
Many final changes.

diff -r d2aacc06e562 -r 477d6a3e5023 en/appB-mq-ref.xml
--- a/en/appB-mq-ref.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/appB-mq-ref.xml	Mon May 04 23:52:38 2009 -0700
@@ -72,6 +72,16 @@
 
     </sect2>
     <sect2>
+      <title><command role="hg-ext-mq">qfold</command>&emdash;move
+	applied patches into repository history</title>
+
+      <para>The <command>hg qfinish</command> command converts the
+	specified applied patches into permanent changes by moving
+	them out of MQ's control so that they will be treated as
+	normal repository history.</para>
+    </sect2>
+
+    <sect2>
       <title><command role="hg-ext-mq">qfold</command>&emdash;merge
 	(<quote>fold</quote>) several patches into one</title>
 
@@ -328,8 +338,8 @@
 	    no such text, a default commit message is used that
 	    identifies the name of the patch.</para>
 	</listitem></itemizedlist>
-      <para id="x_615">If a patch contains a Mercurial patch header (XXX add
-	link), the information in the patch header overrides these
+      <para id="x_615">If a patch contains a Mercurial patch header,
+	the information in the patch header overrides these
 	defaults.</para>
 
       <para id="x_616">Options:</para>
@@ -435,21 +445,6 @@
 
     </sect2>
     <sect2>
-      <title><command
-	  role="hg-ext-mq">qrestore</command>&emdash;restore saved
-	queue state</title>
-
-      <para id="x_628">XXX No idea what this does.</para>
-
-    </sect2>
-    <sect2>
-      <title><command role="hg-ext-mq">qsave</command>&emdash;save
-	current queue state</title>
-
-      <para id="x_629">XXX Likewise.</para>
-
-    </sect2>
-    <sect2>
       <title><command role="hg-ext-mq">qseries</command>&emdash;print
 	the entire patch series</title>
 
@@ -501,9 +496,7 @@
 	    changesets in the backup bundle.</para>
 	</listitem>
 	<listitem><para id="x_631"><option role="hg-opt-strip">-f</option>: If a
-	    branch has multiple heads, remove all heads. XXX This
-	    should be renamed, and use <literal>-f</literal> to strip
-	    revs when there are pending changes.</para>
+	    branch has multiple heads, remove all heads.</para>
 	</listitem>
 	<listitem><para id="x_632"><option role="hg-opt-strip">-n</option>: Do
 	    not save a backup bundle.</para>
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch02-tour-merge.xml
--- a/en/ch02-tour-merge.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch02-tour-merge.xml	Mon May 04 23:52:38 2009 -0700
@@ -146,6 +146,7 @@
 
       &interaction.tour.merge.parents;
     </sect2>
+
     <sect2>
       <title>Committing the results of the merge</title>
 
@@ -292,8 +293,8 @@
 	strengths and weaknesses.  Most are tuned for merging files
 	containing plain text, while a few are aimed at specialised
 	file formats (generally XML).</para>
+    </sect2>
 
-    </sect2>
     <sect2>
       <title>A worked example</title>
 
@@ -365,6 +366,7 @@
       </note>
     </sect2>
   </sect1>
+
   <sect1 id="sec:tour-merge:fetch">
     <title>Simplifying the pull-merge-commit sequence</title>
 
@@ -421,7 +423,27 @@
       the extension, but since the <literal
 	role="hg-ext">fetch</literal> extension is in the standard
       distribution, Mercurial knows where to search for it.)</para>
+  </sect1>
 
+  <sect1>
+    <title>Renaming, copying, and merging</title>
+
+    <para>During the life of a project, we will often want to change
+      the layout of its files and directories. This can be as simple
+      as renaming a single file, or as complex as restructuring the
+      entire hierarchy of files within the project.</para>
+
+    <para>Mercurial supports these kinds of complex changes fluently,
+      provided we tell it what we're doing.  If we want to rename a
+      file, we should use the <command>hg rename</command><footnote>
+	<para>If you're a Unix user, you'll be glad to know that the
+	  <command>hg rename</command> command can be abbreviated as
+	  <command>hg mv</command>.</para>
+      </footnote> command to rename it, so that Mercurial can do the
+      right thing later when we merge.</para>
+
+    <para>We will cover the use of these commands in more detail in
+      <xref linkend="chap:daily.copy"/>.</para>
   </sect1>
 </chapter>
 
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch03-concepts.xml
--- a/en/ch03-concepts.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch03-concepts.xml	Mon May 04 23:52:38 2009 -0700
@@ -112,12 +112,15 @@
       <para id="x_2f3">As the illustration shows, there is
 	<emphasis>not</emphasis> a <quote>one to one</quote>
 	relationship between revisions in the changelog, manifest, or
-	filelog. If the manifest hasn't changed between two
-	changesets, the changelog entries for those changesets will
-	point to the same revision of the manifest.  If a file that
+	filelog. If a file that
 	Mercurial tracks hasn't changed between two changesets, the
 	entry for that file in the two revisions of the manifest will
-	point to the same revision of its filelog.</para>
+	point to the same revision of its filelog<footnote>
+	  <para>It is possible (though unusual) for the manifest to
+	    remain the same between two changesets, in which case the
+	    changelog entries for those changesets will point to the
+	    same revision of the manifest.</para>
+	</footnote>.</para>
 
     </sect2>
   </sect1>
@@ -175,16 +178,18 @@
     <sect2>
       <title>Fast retrieval</title>
 
-      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to all earlier
-	revision control systems: the problem of <emphasis>inefficient
-	  retrieval</emphasis>. Most revision control systems store
-	the contents of a revision as an incremental series of
-	modifications against a <quote>snapshot</quote>.  To
-	reconstruct a specific revision, you must first read the
-	snapshot, and then every one of the revisions between the
-	snapshot and your target revision.  The more history that a
-	file accumulates, the more revisions you must read, hence the
-	longer it takes to reconstruct a particular revision.</para>
+      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to
+	all earlier revision control systems: the problem of
+	<emphasis>inefficient retrieval</emphasis>. Most revision
+	control systems store the contents of a revision as an
+	incremental series of modifications against a
+	<quote>snapshot</quote>.  (Some base the snapshot on the
+	oldest revision, others on the newest.)  To reconstruct a
+	specific revision, you must first read the snapshot, and then
+	every one of the revisions between the snapshot and your
+	target revision.  The more history that a file accumulates,
+	the more revisions you must read, hence the longer it takes to
+	reconstruct a particular revision.</para>
 
       <figure id="fig:concepts:snapshot">
 	<title>Snapshot of a revlog, with incremental deltas</title>
@@ -211,25 +216,15 @@
       <sect3>
 	<title>Aside: the influence of video compression</title>
 
-	<para id="x_2fe">If you're familiar with video compression or have ever
-	  watched a TV feed through a digital cable or satellite
-	  service, you may know that most video compression schemes
-	  store each frame of video as a delta against its predecessor
-	  frame.  In addition, these schemes use <quote>lossy</quote>
-	  compression techniques to increase the compression ratio, so
-	  visual errors accumulate over the course of a number of
-	  inter-frame deltas.</para>
+	<para id="x_2fe">If you're familiar with video compression or
+	  have ever watched a TV feed through a digital cable or
+	  satellite service, you may know that most video compression
+	  schemes store each frame of video as a delta against its
+	  predecessor frame.</para>
 
-	<para id="x_2ff">Because it's possible for a video stream to <quote>drop
-	    out</quote> occasionally due to signal glitches, and to
-	  limit the accumulation of artefacts introduced by the lossy
-	  compression process, video encoders periodically insert a
-	  complete frame (called a <quote>key frame</quote>) into the
-	  video stream; the next delta is generated against that
-	  frame.  This means that if the video signal gets
-	  interrupted, it will resume once the next key frame is
-	  received.  Also, the accumulation of encoding errors
-	  restarts anew with each key frame.</para>
+	<para id="x_2ff">Mercurial borrows this idea to make it
+	  possible to reconstruct a revision from a snapshot and a
+	  small number of deltas.</para>
 
       </sect3>
     </sect2>
@@ -261,9 +256,9 @@
 	uncorrupted sections of the revlog, both before and after the
 	corrupted section.  This would not be possible with a
 	delta-only storage model.</para>
-
     </sect2>
   </sect1>
+
   <sect1>
     <title>Revision history, branching, and merging</title>
 
@@ -314,11 +309,15 @@
       those files, with the same contents it had when the changeset
       was committed.</para>
 
-    <para id="x_309">The <emphasis>dirstate</emphasis> contains Mercurial's
-      knowledge of the working directory.  This details which
-      changeset the working directory is updated to, and all of the
-      files that Mercurial is tracking in the working
-      directory.</para>
+    <para id="x_309">The <emphasis>dirstate</emphasis> is a special
+      structure that contains Mercurial's knowledge of the working
+      directory.  It is maintained as a file named
+      <filename>.hg/dirstate</filename> inside a repository.  The
+      dirstate details which changeset the working directory is
+      updated to, and all of the files that Mercurial is tracking in
+      the working directory. It also lets Mercurial quickly notice
+      changed files, by recording their checkout times and
+      sizes.</para>
 
     <para id="x_30a">Just as a revision of a revlog has room for two parents, so
       that it can represent either a normal revision (with one parent)
@@ -426,9 +425,9 @@
       </figure>
 
       <note>
-	<para id="x_315">  If you're new to Mercurial, you should keep in mind a
-	  common <quote>error</quote>, which is to use the <command
-	    role="hg-cmd">hg pull</command> command without any
+	<para id="x_315">If you're new to Mercurial, you should keep
+	  in mind a common <quote>error</quote>, which is to use the
+	  <command role="hg-cmd">hg pull</command> command without any
 	  options.  By default, the <command role="hg-cmd">hg
 	    pull</command> command <emphasis>does not</emphasis>
 	  update the working directory, so you'll bring new changesets
@@ -436,16 +435,19 @@
 	  synced at the same changeset as before the pull.  If you
 	  make some changes and commit afterwards, you'll thus create
 	  a new head, because your working directory isn't synced to
-	  whatever the current tip is.</para>
+	  whatever the current tip is.  To combine the operation of a
+	  pull, followed by an update, run <command>hg pull
+	    -u</command>.</para>
 
-	<para id="x_316">  I put the word <quote>error</quote> in
-	  quotes because all that you need to do to rectify this
-	  situation is <command role="hg-cmd">hg merge</command>, then
-	  <command role="hg-cmd">hg commit</command>.  In other words,
-	  this almost never has negative consequences; it's just
-	  something of a surprise for newcomers.  I'll discuss other
-	  ways to avoid this behavior, and why Mercurial behaves in
-	  this initially surprising way, later on.</para>
+	<para id="x_316">I put the word <quote>error</quote> in quotes
+	  because all that you need to do to rectify the situation
+	  where you created a new head by accident is
+	  <command role="hg-cmd">hg merge</command>, then <command
+	    role="hg-cmd">hg commit</command>.  In other words, this
+	  almost never has negative consequences; it's just something
+	  of a surprise for newcomers.  I'll discuss other ways to
+	  avoid this behavior, and why Mercurial behaves in this
+	  initially surprising way, later on.</para>
       </note>
 
     </sect2>
@@ -511,13 +513,15 @@
 	working directory has two parents; these will become the
 	parents of the new changeset.</para>
 
-      <para id="x_322">Mercurial lets you perform multiple merges, but you must
-	commit the results of each individual merge as you go.  This
-	is necessary because Mercurial only tracks two parents for
-	both revisions and the working directory.  While it would be
-	technically possible to merge multiple changesets at once, the
-	prospect of user confusion and making a terrible mess of a
-	merge immediately becomes overwhelming.</para>
+      <para id="x_322">Mercurial lets you perform multiple merges, but
+	you must commit the results of each individual merge as you
+	go.  This is necessary because Mercurial only tracks two
+	parents for both revisions and the working directory.  While
+	it would be technically feasible to merge multiple changesets
+	at once, Mercurial avoids this for simplicity.  With multi-way
+	merges, the risks of user confusion, nasty conflict
+	resolution, and making a terrible mess of a merge would grow
+	intolerable.</para>
 
     </sect2>
 
@@ -598,10 +602,17 @@
 	  transferred, yielding better network performance over most
 	  kinds of network.</para>
 
-	<para id="x_329">(If the connection is over <command>ssh</command>,
-	  Mercurial <emphasis>doesn't</emphasis> recompress the
-	  stream, because <command>ssh</command> can already do this
-	  itself.)</para>
+	<para id="x_329">If the connection is over
+	  <command>ssh</command>, Mercurial
+	  <emphasis>doesn't</emphasis> recompress the stream, because
+	  <command>ssh</command> can already do this itself.  You can
+	  tell Mercurial to always use <command>ssh</command>'s
+	  compression feature by editing the
+	  <filename>.hgrc</filename> file in your home directory as
+	  follows.</para>
+
+	<programlisting>[ui]
+ssh = ssh -C</programlisting>
 
       </sect3>
     </sect2>
@@ -611,9 +622,8 @@
       <para id="x_32a">Appending to files isn't the whole story when
 	it comes to guaranteeing that a reader won't see a partial
 	write.  If you recall <xref linkend="fig:concepts:metadata"/>,
-	revisions in
-	the changelog point to revisions in the manifest, and
-	revisions in the manifest point to revisions in filelogs.
+	revisions in the changelog point to revisions in the manifest,
+	and revisions in the manifest point to revisions in filelogs.
 	This hierarchy is deliberate.</para>
 
       <para id="x_32b">A writer starts a transaction by writing filelog and
@@ -637,7 +647,7 @@
 	being written to while the read is occurring. This has a big
 	effect on scalability; you can have an arbitrary number of
 	Mercurial processes safely reading data from a repository
-	safely all at once, no matter whether it's being written to or
+	all at once, no matter whether it's being written to or
 	not.</para>
 
       <para id="x_32e">The lockless nature of reading means that if you're
@@ -709,8 +719,8 @@
 	storage is cheap, and this method gives the highest
 	performance while deferring most book-keeping to the operating
 	system.  An alternative scheme would most likely reduce
-	performance and increase the complexity of the software, each
-	of which is much more important to the <quote>feel</quote> of
+	performance and increase the complexity of the software, but
+	speed and simplicity are key to the <quote>feel</quote> of
 	day-to-day use.</para>
 
     </sect2>
@@ -731,18 +741,32 @@
 	dirstate so that it knows what to do with those files when you
 	commit.</para>
 
-      <para id="x_337">When Mercurial is checking the states of files in the
-	working directory, it first checks a file's modification time.
-	If that has not changed, the file must not have been modified.
-	If the file's size has changed, the file must have been
-	modified.  If the modification time has changed, but the size
-	has not, only then does Mercurial need to read the actual
-	contents of the file to see if they've changed. Storing these
-	few extra pieces of information dramatically reduces the
-	amount of data that Mercurial needs to read, which yields
-	large performance improvements compared to other revision
-	control systems.</para>
+      <para id="x_337">The dirstate helps Mercurial to efficiently
+	  check the status of files in a repository.</para>
 
+      <itemizedlist>
+	<listitem>
+	  <para>When Mercurial checks the state of a file in the
+	    working directory, it first checks a file's modification
+	    time against the time in the dirstate that records when
+	    Mercurial last wrote the file. If the last modified time
+	    is the same as the time when Mercurial wrote the file, the
+	    file must not have been modified, so Mercurial does not
+	    need to check any further.</para>
+	</listitem>
+	<listitem>
+	  <para>If the file's size has changed, the file must have
+	    been modified.  If the modification time has changed, but
+	    the size has not, only then does Mercurial need to
+	    actually read the contents of the file to see if it has
+	    changed.</para>
+	</listitem>
+      </itemizedlist>
+
+      <para>Storing the modification time and size dramatically
+	reduces the number of read operations that Mercurial needs to
+	perform when we run commands like <command>hg status</command>.
+	This results in large performance improvements.</para>
     </sect2>
   </sect1>
 </chapter>
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch04-daily.xml
--- a/en/ch04-daily.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch04-daily.xml	Mon May 04 23:52:38 2009 -0700
@@ -108,10 +108,11 @@
   <sect1>
     <title>How to stop tracking a file</title>
 
-    <para id="x_1af">Once you decide that a file no longer belongs in your
-      repository, use the <command role="hg-cmd">hg remove</command>
-      command. This deletes the file, and tells Mercurial to stop
-      tracking it.  A removed file is represented in the output of
+    <para id="x_1af">Once you decide that a file no longer belongs in
+      your repository, use the <command role="hg-cmd">hg
+	remove</command> command. This deletes the file, and tells
+      Mercurial to stop tracking it (which will occur at the next
+      commit).  A removed file is represented in the output of
       <command role="hg-cmd">hg status</command> with a
       <quote><literal>R</literal></quote>.</para>
 
@@ -214,7 +215,7 @@
     </sect2>
   </sect1>
 
-  <sect1>
+  <sect1 id="chap:daily.copy">
     <title>Copying files</title>
 
     <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg
@@ -535,11 +536,12 @@
       <command role="hg-cmd">hg revert</command> to get rid of
       erroneous changes to a file.</para>
 
-    <para id="x_1e4">It's good to remember that the <command role="hg-cmd">hg
-	revert</command> command is useful for changes that you have
-      not yet committed.  Once you've committed a change, if you
-      decide it was a mistake, you can still do something about it,
-      though your options may be more limited.</para>
+    <para id="x_1e4">It is helpful to remember that the <command
+	role="hg-cmd">hg revert</command> command is useful for
+      changes that you have not yet committed.  Once you've committed
+      a change, if you decide it was a mistake, you can still do
+      something about it, though your options may be more
+      limited.</para>
 
     <para id="x_1e5">For more information about the <command
 	role="hg-cmd">hg revert</command> command, and details about
@@ -817,7 +819,7 @@
 
     <para id="x_6d9">If you perform traditional backups of your master
       repositories to tape or disk, and you want to back up a
-      repository named <filename>myrepo</filename>.  Use <command>hg
+      repository named <filename>myrepo</filename>, use <command>hg
 	clone -U myrepo myrepo.bak</command> to create a
       clone of <filename>myrepo</filename> before you start your
       backups.  The <option>-U</option> option doesn't check out a
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch05-collab.xml
--- a/en/ch05-collab.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch05-collab.xml	Mon May 04 23:52:38 2009 -0700
@@ -55,18 +55,12 @@
 	linkend="sec:collab:serve"/> below for details of how to use
       this command.</para>
 
-    <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 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 id="x_69e">For longer-lived repositories that you'd like to
+      have permanently available, there are several public hosting
+      services available.  Some are free to open source projects,
+      while others offer paid commercial hosting.  An up-to-date list
+      is available at <ulink
+	url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
 
     <para id="x_6a0">If you would prefer to host your own repositories, Mercurial
       has built-in support for several popular hosting technologies,
@@ -827,7 +821,7 @@
 	so that they only print output if they're run interactively.
 	Otherwise these banners will at least clutter up Mercurial's
 	output.  Worse, they could potentially cause problems with
-	running Mercurial commands remotely.  Mercurial makes tries to
+	running Mercurial commands remotely.  Mercurial tries to
 	detect and ignore banners in non-interactive
 	<command>ssh</command> sessions, but it is not foolproof.  (If
 	you're editing your login scripts on your server, the usual
@@ -1107,7 +1101,7 @@
 	  directions inside it to correctly set your
 	  <envar>PYTHONPATH</envar> environment variable.</para>
 
-	<para id="x_4cf">Finally, you are <emphasis>certain</emphasis> to by
+	<para id="x_4cf">Finally, you are <emphasis>certain</emphasis> to be
 	  served with another colourful Python backtrace: this one
 	  will complain that it can't find <filename
 	    class="directory">/path/to/repository</filename>.  Edit
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch06-filenames.xml
--- a/en/ch06-filenames.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch06-filenames.xml	Mon May 04 23:52:38 2009 -0700
@@ -358,10 +358,11 @@
 	  interchangeable is also referred to as <emphasis>case
 	    folding</emphasis>.</para>
       </listitem>
-      <listitem><para id="x_56e">Case sensitive.  The case of a name is
-	  significant at all times. The names <filename>foo</filename>
-	  and {FoO} identify different files.  This is the way Linux
-	  and Unix systems normally work.</para>
+      <listitem><para id="x_56e">Case sensitive.  The case of a name
+	  is significant at all times. The names
+	  <filename>foo</filename> and <filename>FoO</filename>
+	  identify different files.  This is the way Linux and Unix
+	  systems normally work.</para>
       </listitem></itemizedlist>
 
     <para id="x_56f">On Unix-like systems, it is possible to have any or all of
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch07-branch.xml
--- a/en/ch07-branch.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch07-branch.xml	Mon May 04 23:52:38 2009 -0700
@@ -183,15 +183,15 @@
 	after the revision you specified.  This has an interaction
 	with tags that can surprise the unwary.</para>
 
-      <para id="x_381">Recall that a tag is stored as a revision to the <filename
-	  role="special">.hgtags</filename> file, so that when you
-	create a tag, the changeset in which it's recorded necessarily
-	refers to an older changeset.  When you run <command
-	  role="hg-cmd">hg clone -r foo</command> to clone a
-	repository as of tag <literal>foo</literal>, the new clone
-	<emphasis>will not contain the history that created the
-	  tag</emphasis> that you used to clone the repository.  The
-	result is that you'll get exactly the right subset of the
+      <para id="x_381">Recall that a tag is stored as a revision to
+	the <filename role="special">.hgtags</filename> file. When you
+	create a tag, the changeset in which its recorded refers to an
+	older changeset.  When you run <command role="hg-cmd">hg clone
+	  -r foo</command> to clone a repository as of tag
+	<literal>foo</literal>, the new clone <emphasis>will not
+	  contain any revision newer than the one the tag refers to,
+	  including the revision where the tag was created</emphasis>.
+	The result is that you'll get exactly the right subset of the
 	project's history in the new repository, but
 	<emphasis>not</emphasis> the tag you might have
 	expected.</para>
@@ -227,9 +227,10 @@
   <sect1>
     <title>The flow of changes&emdash;big picture vs. little</title>
 
-    <para id="x_384">To return to the outline I sketched at the beginning of a
-      chapter, let's think about a project that has multiple
-      concurrent pieces of work under development at once.</para>
+    <para id="x_384">To return to the outline I sketched at the
+      beginning of the chapter, let's think about a project that has
+      multiple concurrent pieces of work under development at
+      once.</para>
 
     <para id="x_385">There might be a push for a new <quote>main</quote> release;
       a new minor bugfix release to the last main release; and an
@@ -416,7 +417,7 @@
 
     <para id="x_39e">If you have more than one named branch in a repository,
       Mercurial will remember the branch that your working directory
-      on when you start a command like <command role="hg-cmd">hg
+      is on when you start a command like <command role="hg-cmd">hg
 	update</command> or <command role="hg-cmd">hg pull
 	-u</command>.  It will update the working directory to the tip
       of this branch, no matter what the <quote>repo-wide</quote> tip
diff -r d2aacc06e562 -r 477d6a3e5023 en/ch09-hook.xml
--- a/en/ch09-hook.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/ch09-hook.xml	Mon May 04 23:52:38 2009 -0700
@@ -21,6 +21,12 @@
       supports. We will revisit each of these hooks in more detail
       later, in <xref linkend="sec:hook:ref"/>.</para>
 
+    <para id="x_1f6">Each of the hooks whose description begins with the word
+      <quote>Controlling</quote> has the ability to determine whether
+      an activity can proceed.  If the hook succeeds, the activity may
+      proceed; if it fails, the activity is either not permitted or
+      undone, depending on the hook.</para>
+
     <itemizedlist>
       <listitem><para id="x_1e9"><literal role="hook">changegroup</literal>: This
 	  is run after a group of changesets has been brought into the
@@ -87,12 +93,6 @@
 	  finished.
 	</para>
       </listitem></itemizedlist>
-    <para id="x_1f6">Each of the hooks whose description begins with the word
-      <quote>Controlling</quote> has the ability to determine whether
-      an activity can proceed.  If the hook succeeds, the activity may
-      proceed; if it fails, the activity is either not permitted or
-      undone, depending on the hook.
-    </para>
 
   </sect1>
   <sect1>
@@ -139,11 +139,11 @@
 	</para>
       </note>
 
-      <para id="x_1fb">XXX To see what hooks are defined in a repository, use the
-	<command role="hg-cmd">hg config hooks</command> command.  If
-	you are working in one repository, but talking to another that
-	you do not own (e.g. using <command role="hg-cmd">hg
-	  pull</command> or <command role="hg-cmd">hg
+      <para id="x_1fb">To see what hooks are defined in a repository,
+	use the <command role="hg-cmd">hg showconfig hooks</command>
+	command.  If you are working in one repository, but talking to
+	another that you do not own (e.g. using <command
+	  role="hg-cmd">hg pull</command> or <command role="hg-cmd">hg
 	  incoming</command>), remember that it is the other
 	repository's hooks you should be checking, not your own.
       </para>
@@ -585,11 +585,11 @@
 
       &interaction.ch09-hook.ws.better;
 
-      <para id="x_237">As a final aside, note in the example above the use of
-	<command>perl</command>'s in-place editing feature to get rid
-	of trailing whitespace from a file.  This is concise and
-	useful enough that I will reproduce it here.
-      </para>
+      <para id="x_237">As a final aside, note in the example above the
+	use of <command>sed</command>'s in-place editing feature to
+	get rid of trailing whitespace from a file.  This is concise
+	and useful enough that I will reproduce it here (using
+	<command>perl</command> for good measure).</para>
       <programlisting>perl -pi -e 's,\s+$,,' filename</programlisting>
 
     </sect2>
@@ -817,10 +817,7 @@
 		role="rc-item-bugzilla">version</envar>: The version
 	      of Bugzilla installed on the server.  The database
 	      schema that Bugzilla uses changes occasionally, so this
-	      hook has to know exactly which schema to use. At the
-	      moment, the only version supported is
-	      <literal>2.16</literal>.
-	    </para>
+	      hook has to know exactly which schema to use.</para>
 	  </listitem>
 	  <listitem><para id="x_253"><envar role="rc-item-bugzilla">host</envar>:
 	      The hostname of the MySQL server that stores your
diff -r d2aacc06e562 -r 477d6a3e5023 en/examples/auto-snippets.xml
--- a/en/examples/auto-snippets.xml	Sun May 03 20:27:28 2009 -0700
+++ b/en/examples/auto-snippets.xml	Mon May 04 23:52:38 2009 -0700
@@ -57,6 +57,15 @@
 <!ENTITY interaction.ch01-new.init SYSTEM "results/ch01-new.init.lxo">
 <!ENTITY interaction.ch01-new.ls SYSTEM "results/ch01-new.ls.lxo">
 <!ENTITY interaction.ch01-new.ls2 SYSTEM "results/ch01-new.ls2.lxo">
+<!ENTITY interaction.ch02-rename.alice SYSTEM "results/ch02-rename.alice.lxo">
+<!ENTITY interaction.ch02-rename.bob SYSTEM "results/ch02-rename.bob.lxo">
+<!ENTITY interaction.ch02-rename.clone SYSTEM "results/ch02-rename.clone.lxo">
+<!ENTITY interaction.ch02-rename.clone2 SYSTEM "results/ch02-rename.clone2.lxo">
+<!ENTITY interaction.ch02-rename.init SYSTEM "results/ch02-rename.init.lxo">
+<!ENTITY interaction.ch02-rename.merge SYSTEM "results/ch02-rename.merge.lxo">
+<!ENTITY interaction.ch02-rename.merge2 SYSTEM "results/ch02-rename.merge2.lxo">
+<!ENTITY interaction.ch02-rename.status SYSTEM "results/ch02-rename.status.lxo">
+<!ENTITY interaction.ch02-rename.status2 SYSTEM "results/ch02-rename.status2.lxo">
 <!ENTITY interaction.ch04-diff.chmod SYSTEM "results/ch04-diff.chmod.lxo">
 <!ENTITY interaction.ch04-diff.chmod.git SYSTEM "results/ch04-diff.chmod.git.lxo">
 <!ENTITY interaction.ch04-diff.rename.basic SYSTEM "results/ch04-diff.rename.basic.lxo">
@@ -88,6 +97,19 @@
 <!ENTITY interaction.daily.copy.dir-src-dest SYSTEM "results/daily.copy.dir-src-dest.lxo">
 <!ENTITY interaction.daily.copy.init SYSTEM "results/daily.copy.init.lxo">
 <!ENTITY interaction.daily.copy.merge SYSTEM "results/daily.copy.merge.lxo">
+<!ENTITY interaction.daily.copy.orig.after SYSTEM "results/daily.copy.orig.after.lxo">
+<!ENTITY interaction.daily.copy.orig.cat SYSTEM "results/daily.copy.orig.cat.lxo">
+<!ENTITY interaction.daily.copy.orig.clone SYSTEM "results/daily.copy.orig.clone.lxo">
+<!ENTITY interaction.daily.copy.orig.copy SYSTEM "results/daily.copy.orig.copy.lxo">
+<!ENTITY interaction.daily.copy.orig.dir-dest SYSTEM "results/daily.copy.orig.dir-dest.lxo">
+<!ENTITY interaction.daily.copy.orig.dir-src SYSTEM "results/daily.copy.orig.dir-src.lxo">
+<!ENTITY interaction.daily.copy.orig.dir-src-dest SYSTEM "results/daily.copy.orig.dir-src-dest.lxo">
+<!ENTITY interaction.daily.copy.orig.init SYSTEM "results/daily.copy.orig.init.lxo">
+<!ENTITY interaction.daily.copy.orig.merge SYSTEM "results/daily.copy.orig.merge.lxo">
+<!ENTITY interaction.daily.copy.orig.other SYSTEM "results/daily.copy.orig.other.lxo">
+<!ENTITY interaction.daily.copy.orig.simple SYSTEM "results/daily.copy.orig.simple.lxo">
+<!ENTITY interaction.daily.copy.orig.status SYSTEM "results/daily.copy.orig.status.lxo">
+<!ENTITY interaction.daily.copy.orig.status-copy SYSTEM "results/daily.copy.orig.status-copy.lxo">
 <!ENTITY interaction.daily.copy.other SYSTEM "results/daily.copy.other.lxo">
 <!ENTITY interaction.daily.copy.simple SYSTEM "results/daily.copy.simple.lxo">
 <!ENTITY interaction.daily.copy.status SYSTEM "results/daily.copy.status.lxo">
diff -r d2aacc06e562 -r 477d6a3e5023 en/examples/daily.copy
--- a/en/examples/daily.copy	Sun May 03 20:27:28 2009 -0700
+++ b/en/examples/daily.copy	Mon May 04 23:52:38 2009 -0700
@@ -51,9 +51,9 @@
 cd copy-example
 echo a > a
 echo b > b
-mkdir c
-mkdir c/a
-echo c > c/a/c
+mkdir z
+mkdir z/a
+echo c > z/a/c
 hg ci -Ama
 
 #$ name: simple
@@ -70,13 +70,13 @@
 
 #$ name: dir-src
 
-hg copy c e
+hg copy z e
 
 #$ name: dir-src-dest
 
-hg copy c d
+hg copy z d
 
 #$ name: after
 
-cp a z
-hg copy --after a z
+cp a n
+hg copy --after a n
diff -r d2aacc06e562 -r 477d6a3e5023 en/examples/tour
--- a/en/examples/tour	Sun May 03 20:27:28 2009 -0700
+++ b/en/examples/tour	Mon May 04 23:52:38 2009 -0700
@@ -151,13 +151,18 @@
 cp hello.c ../new-hello.c
 sed -i '/printf("hello,/i\\tprintf("once more, hello.\\n");' ../new-hello.c
 
+my-text-editor()
+{
+cp ../new-hello.c hello.c
+}
+
 #$ name: merge.clone
 
 cd ..
 hg clone hello my-new-hello
 cd my-new-hello
-# The file new-hello.c is lightly edited.
-cp ../new-hello.c hello.c
+# Make some simple edits to hello.c.
+my-text-editor hello.c
 hg commit -m 'A new hello for a new day.'
 
 #$ name: merge.dummy2