1.1 --- a/en/ch04-daily.xml	Mon Mar 30 16:23:33 2009 +0800
     1.2 +++ b/en/ch04-daily.xml	Thu Apr 09 22:52:16 2009 -0700
     1.3 @@ -44,7 +44,7 @@
     1.4      <sect2>
     1.5        <title>Explicit versus implicit file naming</title>
     1.6  
     1.7 -      <para id="x_1a7">A useful behaviour that Mercurial has is that if you pass
     1.8 +      <para id="x_1a7">A useful behavior that Mercurial has is that if you pass
     1.9  	the name of a directory to a command, every Mercurial command
    1.10  	will treat this as <quote>I want to operate on every file in
    1.11  	  this directory and its subdirectories</quote>.</para>
    1.12 @@ -66,11 +66,11 @@
    1.13  	extra step of printing the name of each file that it does
    1.14  	something with.  This makes it more clear what is happening,
    1.15  	and reduces the likelihood of a silent and nasty surprise.
    1.16 -	This behaviour is common to most Mercurial commands.</para>
    1.17 -
    1.18 -    </sect2>
    1.19 -    <sect2>
    1.20 -      <title>Aside: Mercurial tracks files, not directories</title>
    1.21 +	This behavior is common to most Mercurial commands.</para>
    1.22 +
    1.23 +    </sect2>
    1.24 +    <sect2>
    1.25 +      <title>Mercurial tracks files, not directories</title>
    1.26  
    1.27        <para id="x_1ab">Mercurial does not track directory information.  Instead,
    1.28  	it tracks the path to a file.  Before creating a file, it
    1.29 @@ -277,7 +277,7 @@
    1.30      <sect2 id="sec:daily:why-copy">
    1.31        <title>Why should changes follow copies?</title>
    1.32  
    1.33 -      <para id="x_1c4">This behaviour, of changes to a file propagating out to
    1.34 +      <para id="x_1c4">This behavior, of changes to a file propagating out to
    1.35  	copies of the file, might seem esoteric, but in most cases
    1.36  	it's highly desirable.</para>
    1.37  
    1.38 @@ -330,7 +330,7 @@
    1.39  	the new copy by hand.  Before you do so, though, please do
    1.40  	reread <xref linkend="sec:daily:why-copy"/>, and make
    1.41  	an informed
    1.42 -	decision that this behaviour is not appropriate to your
    1.43 +	decision that this behavior is not appropriate to your
    1.44  	specific case.</para>
    1.45  
    1.46      </sect2>
    1.47 @@ -345,7 +345,7 @@
    1.48  	  role="hg-cmd">hg copy</command> it without first having
    1.49  	committed those changes, the new copy will also contain the
    1.50  	modifications you have made up until that point.  (I find this
    1.51 -	behaviour a little counterintuitive, which is why I mention it
    1.52 +	behavior a little counterintuitive, which is why I mention it
    1.53  	here.)</para>
    1.54  
    1.55        <para id="x_1cd">The <command role="hg-cmd">hg copy</command> command acts
    1.56 @@ -421,7 +421,7 @@
    1.57        <command role="hg-cmd">hg copy</command>, you can tell Mercurial
    1.58        about a rename after the fact using the <option
    1.59  	role="hg-opt-rename">--after</option> option.  In most other
    1.60 -      respects, the behaviour of the <command role="hg-cmd">hg
    1.61 +      respects, the behavior of the <command role="hg-cmd">hg
    1.62  	rename</command> command, and the options it accepts, are
    1.63        similar to the <command role="hg-cmd">hg copy</command>
    1.64        command.</para>
    1.65 @@ -472,7 +472,7 @@
    1.66  	file ought to be named.</para>
    1.67  
    1.68        <para id="x_1de">What do you think should happen when they merge their
    1.69 -	work? Mercurial's actual behaviour is that it always preserves
    1.70 +	work? Mercurial's actual behavior is that it always preserves
    1.71  	<emphasis>both</emphasis> names when it merges changesets that
    1.72  	contain divergent renames.</para>
    1.73