[svnbook] r4387 committed - Finish issue 65 ("Please talk about the cases where a true DVCS like...

svnbook at googlecode.com svnbook at googlecode.com
Fri Feb 1 12:39:35 CST 2013


Revision: 4387
Author:   cmpilato at gmail.com
Date:     Fri Feb  1 10:39:22 2013
Log:      Finish issue 65 ("Please talk about the cases where a true DVCS  
like
Git would be better than SVN") to the degree that I plan to do so.

* en/book/ch00-preface.xml
   (svn.intro.righttool): Rework this section to make a distinction
     between "choosing version control" and "choosing Subversion", and
     then try to make an honest attempt to quickly explain how
     Subversion differs from the DVCS tools and why one might (or might
     not) choose it over such a tool.

http://code.google.com/p/svnbook/source/detail?r=4387

Modified:
  /trunk/en/book/ch00-preface.xml

=======================================
--- /trunk/en/book/ch00-preface.xml	Fri Aug 31 22:20:48 2012
+++ /trunk/en/book/ch00-preface.xml	Fri Feb  1 10:39:22 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>





More information about the svnbook-dev mailing list