Bryan O'Sullivan avatar Bryan O'Sullivan committed b338f54

Americanize spellings :-(

Comments (0)

Files changed (12)

en/appA-cmdref.xml

 unified diff format, see <xref linkend="sec:mq:patch"/>.</para>
 
 <para id="x_656">By default, this command does not print diffs for files that Mercurial
-considers to contain binary data.  To control this behaviour, see the
+considers to contain binary data.  To control this behavior, see the
 <option role="hg-opt-diff">-a</option> and <option role="hg-opt-diff">--git</option> options.</para>
 
 <sect2>

en/appB-mq-ref.xml

 	files in the working directory, it will refuse to create a new
 	patch unless the <option
 	  role="hg-ext-mq-cmd-qnew-opt">-f</option> option is used
-	(see below).  This behaviour allows you to <command
+	(see below).  This behavior allows you to <command
 	  role="hg-ext-mq">qrefresh</command> your topmost applied
 	patch before you apply a new patch on top of it.</para>
 
 
       <para id="x_608">By default, the <command role="hg-ext-mq">qpop</command>
 	command will not pop any patches if the working directory has
-	been modified.  You can override this behaviour using the
+	been modified.  You can override this behavior using the
 	<option role="hg-ext-mq-cmd-qpop-opt">-f</option> option,
 	which reverts all modifications in the working
 	directory.</para>

en/ch00-preface.xml

 
     <para id="x_85">The advantage of this approach is that the examples are
       always accurate; they describe <emphasis>exactly</emphasis> the
-      behaviour of the version of Mercurial that's mentioned at the
+      behavior of the version of Mercurial that's mentioned at the
       front of the book.  If I update the version of Mercurial that
       I'm documenting, and the output of some command changes, the
       build fails.</para>
 
     <para id="x_88">So when you're reading examples, don't place too much weight
       on the dates or times you see in the output of commands.  But
-      <emphasis>do</emphasis> be confident that the behaviour you're
+      <emphasis>do</emphasis> be confident that the behavior you're
       seeing is consistent and reproducible.</para>
 
   </sect1>

en/ch03-concepts.xml

     <emphasis>efficient</emphasis>.  And just as importantly, if it's
     easy for me to retain a good idea of what the software is doing
     when I perform a revision control task, I'm less likely to be
-    surprised by its behaviour.</para>
+    surprised by its behavior.</para>
 
   <para id="x_2ea">In this chapter, we'll initially cover the core concepts
     behind Mercurial's design, then continue to discuss some of the
 	  <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 behaviour, and why Mercurial behaves in
+	  ways to avoid this behavior, and why Mercurial behaves in
 	  this initially surprising way, later on.</para>
       </note>
 

en/ch04-daily.xml

     <sect2>
       <title>Explicit versus implicit file naming</title>
 
-      <para id="x_1a7">A useful behaviour that Mercurial has is that if you pass
+      <para id="x_1a7">A useful behavior that Mercurial has is that if you pass
 	the name of a directory to a command, every Mercurial command
 	will treat this as <quote>I want to operate on every file in
 	  this directory and its subdirectories</quote>.</para>
 	extra step of printing the name of each file that it does
 	something with.  This makes it more clear what is happening,
 	and reduces the likelihood of a silent and nasty surprise.
-	This behaviour is common to most Mercurial commands.</para>
+	This behavior is common to most Mercurial commands.</para>
 
     </sect2>
     <sect2>
-      <title>Aside: Mercurial tracks files, not directories</title>
+      <title>Mercurial tracks files, not directories</title>
 
       <para id="x_1ab">Mercurial does not track directory information.  Instead,
 	it tracks the path to a file.  Before creating a file, it
     <sect2 id="sec:daily:why-copy">
       <title>Why should changes follow copies?</title>
 
-      <para id="x_1c4">This behaviour, of changes to a file propagating out to
+      <para id="x_1c4">This behavior, of changes to a file propagating out to
 	copies of the file, might seem esoteric, but in most cases
 	it's highly desirable.</para>
 
 	the new copy by hand.  Before you do so, though, please do
 	reread <xref linkend="sec:daily:why-copy"/>, and make
 	an informed
-	decision that this behaviour is not appropriate to your
+	decision that this behavior is not appropriate to your
 	specific case.</para>
 
     </sect2>
 	  role="hg-cmd">hg copy</command> it without first having
 	committed those changes, the new copy will also contain the
 	modifications you have made up until that point.  (I find this
-	behaviour a little counterintuitive, which is why I mention it
+	behavior a little counterintuitive, which is why I mention it
 	here.)</para>
 
       <para id="x_1cd">The <command role="hg-cmd">hg copy</command> command acts
       <command role="hg-cmd">hg copy</command>, you can tell Mercurial
       about a rename after the fact using the <option
 	role="hg-opt-rename">--after</option> option.  In most other
-      respects, the behaviour of the <command role="hg-cmd">hg
+      respects, the behavior of the <command role="hg-cmd">hg
 	rename</command> command, and the options it accepts, are
       similar to the <command role="hg-cmd">hg copy</command>
       command.</para>
 	file ought to be named.</para>
 
       <para id="x_1de">What do you think should happen when they merge their
-	work? Mercurial's actual behaviour is that it always preserves
+	work? Mercurial's actual behavior is that it always preserves
 	<emphasis>both</emphasis> names when it merges changesets that
 	contain divergent renames.</para>
 

en/ch05-collab.xml

 
       <para id="x_4b6">Mercurial does not compress data when it uses the ssh
 	protocol, because the ssh protocol can transparently compress
-	data.  However, the default behaviour of ssh clients is
+	data.  However, the default behavior of ssh clients is
 	<emphasis>not</emphasis> to request compression.</para>
 
       <para id="x_4b7">Over any network other than a fast LAN (even a wireless
 	<para id="x_4fd">If you add <literal role="rc-web">web</literal> items to
 	  your own personal <filename role="special">~/.hgrc</filename> file, CGI scripts won't read that
 	  <filename role="special">~/.hgrc</filename> file.  Those
-	  settings will thus only affect the behaviour of the <command
+	  settings will thus only affect the behavior of the <command
 	    role="hg-cmd">hg serve</command> command when you run it.
 	  To cause CGI scripts to see your settings, either create a
 	  <filename role="special">~/.hgrc</filename> file in the

en/ch06-filenames.xml

     <title>Running commands without any file names</title>
 
     <para id="x_547">Mercurial's commands that work with file names have useful
-      default behaviours when you invoke them without providing any
-      file names or patterns.  What kind of behaviour you should
+      default behaviors when you invoke them without providing any
+      file names or patterns.  What kind of behavior you should
       expect depends on what the command does.  Here are a few rules
       of thumb you can use to predict what a command is likely to do
       if you don't give it any names to work with.</para>
 	  arguments, for example.</para>
       </listitem></itemizedlist>
 
-    <para id="x_54a">It's easy to work around these default behaviours if they
+    <para id="x_54a">It's easy to work around these default behaviors if they
       don't suit you.  If a command normally operates on the whole
       working directory, you can invoke it on just the current
       directory and its subdirectories by giving it the name

en/ch07-branch.xml

       you may need to use the <option role="hg-opt-update">-C</option>
       option to <command role="hg-cmd">hg update</command>.</para>
 
-    <para id="x_39f">This behaviour is a little subtle, so let's see it in
+    <para id="x_39f">This behavior is a little subtle, so let's see it in
       action.  First, let's remind ourselves what branch we're
       currently on, and what branches are in our repository.</para>
 
 	occurred in the repository. This means that you can only roll
 	back one transaction.  If you expect to be able to roll back
 	one transaction, then its predecessor, this is not the
-	behaviour you will get.</para>
+	behavior you will get.</para>
 
       &interaction.rollback.twice;
 
 
     <para id="x_127">The idea behind the <command role="hg-cmd">hg
 	bisect</command> command is that a changeset has introduced
-      some change of behaviour that you can identify with a simple
+      some change of behavior that you can identify with a simple
       binary test.  You don't know which piece of code introduced the
       change, but you know how to test for the presence of the bug.
       The <command role="hg-cmd">hg bisect</command> command uses your
 	changesets or months of history, you will only add a handful
 	of tests to the total number that <command role="hg-cmd">hg
 	  bisect</command> must perform, thanks to its logarithmic
-	behaviour.</para>
+	behavior.</para>
 
     </sect2>
   </sect1>
 
       <para id="x_200">Mercurial allows you to override a hook definition by
 	redefining the hook.  You can disable it by setting its value
-	to the empty string, or change its behaviour as you wish.
+	to the empty string, or change its behavior as you wish.
       </para>
 
       <para id="x_201">If you deploy a system- or site-wide <filename
 	  comment; you specify it in the form of a Mercurial template.
 	  Several <filename role="special">~/.hgrc</filename> entries
 	  (still in the <literal role="rc-bugzilla">bugzilla</literal>
-	  section) control this behaviour.
+	  section) control this behavior.
 	</para>
 	<itemizedlist>
 	  <listitem><para id="x_25e"><literal>strip</literal>: The number of
 
     <para id="x_3b3">During the late 1990s, several Linux kernel developers
       started to maintain <quote>patch series</quote> that modified
-      the behaviour of the Linux kernel.  Some of these series were
+      the behavior of the Linux kernel.  Some of these series were
       focused on stability, some on feature coverage, and others were
       more speculative.</para>
 
 
       <para id="x_3ba">In mid-2005, Chris Mason took the features of quilt and
 	wrote an extension that he called Mercurial Queues, which
-	added quilt-like behaviour to Mercurial.</para>
+	added quilt-like behavior to Mercurial.</para>
 
       <para id="x_3bb">The key difference between quilt and MQ is that quilt
 	knows nothing about revision control systems, while MQ is

en/ch13-hgext.xml

       the background and receives notifications from the
       <literal>inotify</literal> subsystem.  It also listens for
       connections from a regular Mercurial command.  The extension
-      modifies Mercurial's behaviour so that instead of scanning the
+      modifies Mercurial's behavior so that instead of scanning the
       filesystem, it queries the daemon.  Since the daemon has perfect
       information about the state of the repository, it can respond
       with a result instantaneously, avoiding the need to scan every
     <para id="x_520">When you're using the <literal
 	role="hg-ext">inotify</literal> extension, you should notice
       <emphasis>no difference at all</emphasis> in Mercurial's
-      behaviour, with the sole exception of status-related commands
+      behavior, with the sole exception of status-related commands
       running a whole lot faster than they used to.  You should
       specifically expect that commands will not print different
       output; neither should they give different results. If either of
       purpose of the series of changes you're sending.</para>
 
     <sect2>
-      <title>Changing the behaviour of patchbombs</title>
+      <title>Changing the behavior of patchbombs</title>
 
       <para id="x_53b">Not every project has exactly the same conventions for
 	sending changes in email; the <literal
 	    option.  This takes one argument, the email address to
 	    use.</para>
 	</listitem>
-	<listitem><para id="x_53e">The default behaviour is to send unified diffs
+	<listitem><para id="x_53e">The default behavior is to send unified diffs
 	    (see <xref linkend="sec:mq:patch"/> for a
 	    description of the
 	    format), one per message.  You can send a binary bundle
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.