comparison en/ch00-preface.xml @ 766:3b33dd6aba87

Merge with http://hg.serpentine.com/mercurial/book

765:d8c85d831fb4

	<listitem><para id="x_75">It will help you to work simultaneously on,
	    and manage the drift between, multiple versions of your
	    project.</para></listitem>
      </itemizedlist>

      <para id="x_76">Most of these reasons are equally valid---at least in
	theory---whether you're working on a project by yourself, or
	with a hundred other people.</para>

      <para id="x_77">A key question about the practicality of revision control
	at these two different scales (<quote>lone hacker</quote> and
	<quote>huge team</quote>) is how its
	<emphasis>benefits</emphasis> compare to its

  </sect1>
  <sect1>
    <title>About the examples in this book</title>

    <para id="x_84">This book takes an unusual approach to code samples.  Every
      example is <quote>live</quote>---each one is actually the result
      of a shell script that executes the Mercurial commands you see.
      Every time an image of the book is built from its sources, all
      the example scripts are automatically run, and their current
      results compared against their expected results.</para>

      <para id="x_9a">Centralised revision control systems tend to have
	relatively low scalability.  It's not unusual for an expensive
	centralised system to fall over under the combined load of
	just a few dozen concurrent users.  Once again, the typical
	response tends to be an expensive and clunky replication
	facility.  Since the load on a central server---if you have
	one at all---is many times lower with a distributed tool
	(because all of the data is replicated everywhere), a single
	cheap server can handle the needs of a much larger team, and
	replication to balance load becomes a simple matter of
	scripting.</para>

766:3b33dd6aba87

	<listitem><para id="x_75">It will help you to work simultaneously on,
	    and manage the drift between, multiple versions of your
	    project.</para></listitem>
      </itemizedlist>

      <para id="x_76">Most of these reasons are equally
	valid&emdash;at least in theory&emdash;whether you're working
	on a project by yourself, or with a hundred other
	people.</para>

      <para id="x_77">A key question about the practicality of revision control
	at these two different scales (<quote>lone hacker</quote> and
	<quote>huge team</quote>) is how its
	<emphasis>benefits</emphasis> compare to its

  </sect1>
  <sect1>
    <title>About the examples in this book</title>

    <para id="x_84">This book takes an unusual approach to code samples.  Every
      example is <quote>live</quote>&emdash;each one is actually the result
      of a shell script that executes the Mercurial commands you see.
      Every time an image of the book is built from its sources, all
      the example scripts are automatically run, and their current
      results compared against their expected results.</para>

      <para id="x_9a">Centralised revision control systems tend to have
	relatively low scalability.  It's not unusual for an expensive
	centralised system to fall over under the combined load of
	just a few dozen concurrent users.  Once again, the typical
	response tends to be an expensive and clunky replication
	facility.  Since the load on a central server&emdash;if you have
	one at all&emdash;is many times lower with a distributed tool
	(because all of the data is replicated everywhere), a single
	cheap server can handle the needs of a much larger team, and
	replication to balance load becomes a simple matter of
	scripting.</para>