Commits

Bryan O'Sullivan committed 477d6a3

Many final changes.

Comments (0)

Files changed (11)

en/appB-mq-ref.xml

 
     </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>
 
 	    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>
 
     </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>
 
 	    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>

en/ch02-tour-merge.xml

 
       &interaction.tour.merge.parents;
     </sect2>
+
     <sect2>
       <title>Committing the results of the merge</title>
 
 	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>
 
       </note>
     </sect2>
   </sect1>
+
   <sect1 id="sec:tour-merge:fetch">
     <title>Simplifying the pull-merge-commit sequence</title>
 
       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>
 

en/ch03-concepts.xml

       <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>
     <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>
       <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>
 	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>
 
       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)
       </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
 	  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>
 	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>
 
 	  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>
       <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
 	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
 	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>
 	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>

en/ch04-daily.xml

   <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>
 
     </sect2>
   </sect1>
 
-  <sect1>
+  <sect1 id="chap:daily.copy">
     <title>Copying files</title>
 
     <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg
       <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
 
     <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

en/ch05-collab.xml

 	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,
 	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
 	  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

en/ch06-filenames.xml

 	  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

en/ch07-branch.xml

 	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>
   <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
 
     <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
       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
 	  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>
 	</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>
 
       &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>
 		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

en/examples/auto-snippets.xml

 <!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">
 <!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">

en/examples/daily.copy

 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
 
 #$ 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
 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
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.