[svnbook] r4388 committed - Merge from ^/trunk/en r4387 (moderize the '... Right Tool?' section).

[svnbook at googlecode.com]

Revision: 4388
Author:   cmpilato at gmail.com
Date:     Fri Feb  1 10:44:07 2013
Log:      Merge from ^/trunk/en r4387 (moderize the '... Right Tool?'  
section).
http://code.google.com/p/svnbook/source/detail?r=4388

Modified:
  /branches/1.7/en
  /branches/1.7/en/book/ch00-preface.xml

=======================================
--- /branches/1.7/en/book/ch00-preface.xml	Sat Oct 29 21:37:07 2011
+++ /branches/1.7/en/book/ch00-preface.xml	Fri Feb  1 10:44:07 2013
@@ -121,43 +121,111 @@
          fantastic hammer, but be careful not to view every problem as
          a nail.</para>

-      <para>If you need to archive old versions of files and
-        directories, possibly resurrect them, or examine logs of how
-        they've changed over time, then Subversion is exactly the
-        right tool for you.  If you need to collaborate with people on
-        documents (usually over a network) and keep track of who made
-        which changes, then Subversion is also appropriate.  This is
-        why Subversion is so often used in software development
+      <para>As a first step, you need to decide if version control in
+        general is required for your purposes.  If you need to archive
+        old versions of files and directories, possibly resurrect
+        them, and examine logs of how they've changed over time, then
+        version control tools can do that.  If you need to collaborate
+        with people on documents (usually over a network) and keep
+        track of who made which changes, a version control tool can do
+        that, too.  In fact, this is why version control tools such as
+        Subversion are so often used in software development
          environments—working on a development team is an
-        inherently social activity, and Subversion makes it easy to
-        collaborate with other programmers.  Of course, there's a cost
-        to using Subversion as well: administrative overhead.  You'll
-        need to manage a data repository to store the information and
-        all its history, and be diligent about backing it up.  When
-        working with the data on a daily basis, you won't be able to
-        copy, move, rename, or delete files the way you usually do.
-        Instead, you'll have to do all of those things through
-        Subversion.</para>
+        inherently social activity where changes to source code files
+        are constantly being discussed, made, evaluated, and even
+        sometimes unmade.  Version control tools facilitate that sort
+        of collaboration.</para>

-      <para>Assuming you're fine with the extra workflow, you should
-        still make sure you're not using Subversion to solve a problem
-        that other tools solve better.  For example, because
-        Subversion replicates data to all the collaborators involved,
-        a common misuse is to treat it as a generic distribution
-        system.  People will sometimes use Subversion to distribute
-        huge collections of photos, digital music, or software
-        packages.  The problem is that this sort of data usually isn't
-        changing at all.  The collection itself grows over time, but
-        the individual files within the collection aren't being
-        changed.  In this case, using Subversion
-        is <quote>overkill.</quote><footnote><para>Or as a friend puts
+      <para>There is cost associated with using version control, too.
+        Unless you can outsource the administration of your version
+        control system to a third-party, you'll have the obvious costs
+        of performing that administration yourself.  When working with
+        the data on a daily basis, you won't be able to copy, move,
+        rename, or delete files the way you usually do.  Instead,
+        you'll have to do all of those things through the version
+        control system.</para>
+
+      <para>Even assuming that you are okay with the cost/benefit
+        tradeoff afforded by a version control system, you shouldn't
+        choose to use one merely because it <emphasis>can</emphasis>
+        do what you want.  Consider whether your needs are better
+        addressed by other tools.  For example, because Subversion
+        replicates data to all the collaborators involved, a common
+        misuse is to treat it as a generic distribution system.
+        People will sometimes use Subversion to distribute huge
+        collections of photos, digital music, or software packages.
+        The problem is that this sort of data usually isn't changing
+        at all.  The collection itself grows over time, but the
+        individual files within the collection aren't being changed.
+        In this case, using Subversion is
+        <quote>overkill.</quote><footnote><para>Or as a friend puts
          it, <quote>swatting a fly with a
          Buick.</quote></para></footnote> There are simpler tools that
          efficiently replicate data <emphasis>without</emphasis> the
          overhead of tracking changes, such as <command>rsync</command>
          or <command>unison</command>.</para>

-      <!-- TODO: Fill in the landscape with respect to DVCS -->
+      <para>Once you've decided that you need a version control
+        solution, you'll find no shortage of available options.  When
+        Subversion was first designed and released, the predominant
+        methodology of version control was <firstterm>centralized
+        version control</firstterm>—a single remote master
+        storehouse of versioned data with individual users operating
+        locally against shallow copies of that data's version history.
+        Subversion quickly emerged after its initial introduction as
+        the clear leader in this field of version control, earning
+        widespread adoption and supplanting installations of many
+        older version control systems.  It continues to hold that
+        prominent position today.</para>
+
+      <para>Much as changed since that time, though.  In the years
+        since the Subversion project began its life, a newer
+        methodology of version control called <firstterm>distributed
+        version control</firstterm> has likewise garnered widespread
+        attention and adoption.  Tools such as Git
+        (<ulink url="http://git-scm.com/" />) and Mercurial
+        (<ulink url="http://mercurial.selenic.com/" />) quickly rose
+        to the tops of the distributed version control system (DVCS)
+        ranks.  Distributed version control harnesses the growing
+        ubiquity of high-speed network connections and low storage
+        costs to offer an approach which differs from the centralized
+        model in key ways.  First and most obvious is the fact that
+        there is no remote, central storehouse of versioned data.
+        Rather, each user keeps and operates against very
+        deep—complete, in a sense—local version history
+        data stores.  Collaboration still occurs, but is accomplished
+        by trading <firstterm>changesets</firstterm> (collections of
+        changes made to versioned items) directly between users' local
+        data stores, not via a centralized master data store.  In
+        fact, any semblance of a canonical <quote>master</quote>
+        source of a project's versioned data is by convention only, a
+        status attributed by the various collaborators on that
+        project.</para>
+
+      <para>There are pros and cons to each version control approach.
+        Perhaps the two biggest benefits delivered by the DVCS tools
+        are incredible performance for day-to-day operations and
+        vastly better support for merging between branches.  The
+        downside is that distribute version control is an inherently
+        more complicated model, which can present a non-negligible
+        challenge to comfortable collaboration.  With centralized
+        version control, you may find a greater degree of control over
+        your versioned assets, especially as regards access control.
+        Fortunately, many wise organizations have discovered that this
+        needn't be a religious debate, and that Subversion and a DVCS
+        tool such as Git can be used together harmoniously within the
+        organization, each serving the purposes best suited to the
+        tool.</para>
+
+      <para>Alas, this book is about Subversion, so we'll not attempt
+        a full comparison of Subversion and other tools.  Readers who
+        have the option of choosing their version control system are
+        encouraged to research the available options and make the
+        determination that works best for themselves and their fellow
+        collaborators.  And if, after doing so, Subversion is the
+        chosen tool, there's <emphasis>plenty</emphasis> of detailed
+        information about how to use it successfully in the chapters
+        that follow!</para>

      </sect2>