Switching from CVS to Subversion: test svn repo available

[Chris Shoemaker]

        SVN is clearly superior to CVS.  SVN basically seems like a
faster, less-annoying, more-featureful version of CVS.  But, like CVS, it
was never intended to be a SCM system [1], it's just a version control
system.  Since we're obviously writing software, I think a real SCM
has compelling advantages.  So, I'd like everybody to also consider
some other SCMs, especially of the distributed variety.

        Here are a few reasons why: 

** Changesets **
        SVN perpetuates what is, in my opinion, a horrible disease
instituted by CVS: the idea that users care about FILE history, but
not PROJECT history.  Its model is: the repository is a collection of
files that have version history.  (I realize they can be renamed.)

        Alternatively, for another breed of SCMs the model is: the
repository is a project that has history, which happens to be
represented by files.  This distinction may (or may not?) seem subtle
but it is HUGE.  This is the whole concept of
changesets/patchsets/commits-whatever.  It lets the user view and
operate atomically on "changesets" that affect many files.  This is
*SO* useful, that once you're used to it, not being able to do it just
seems like wandering around in the dark with you hands tied behind
your back.  
        [ SCMs that implement this concept include tla (aka arch),
darcs, bitkeeper, cogito, mecurial, and others. ]

** Centralized vs. Distributed **
        SVN is centralized.  I know SVN+SVK is distributed.  But, I
want to make the case that distributed is not "gravy" but an important
feature.  Then we can evaluate SVN+SVK alongside other distributed
systems.
        IMO, the reason distributed SCM is important boils down to
"fringe" developer convenience.  I grant that, for core-developers,
distributed SCM *may* not offer compelling advantages, but for
"fringe" developers distributed SCM offers substantial benefit.
        Who are those fringe developers?  The casual patch submitter,
the aspiring core developer, and the occasional on again, off again,
developer, etc.
        What are those benefits?  Easier to share/review code while
maintaining full incremental history of development.  Smaller
contribution hunks, since the "commits" are made at development time,
to someone's local tree.  That, in turn, means better log
descriptions.  Easier maintenance of experimental branches: Because:
 
          *** Distributed SCM allows even "fringe" developers 
              to have the benefits of a full-blown SCM. ***

        Why should the core developers care?  Because some "fringe"
developers may become core developers, and Gnucash needs more
developers.

** Logging **
        Logging is important enough to do well.  Keeping two sets of
logs, commit-time logs, plus ChangeLog file, is difficult,
less-useful, and error-prone.  With CVS it was a necessary evil, since
at very minimum, it's important to associate related changes in
multiple files.  (It seems this problem would remain with SVN.)
        A good SCM keeps commit logs sufficient for logging both the
file histories and the project history.  Then, the "ChangeLog" comes
directly out of the SCM and contains exactly the information that it
should, and it's automatically correct.

** Summary **
        In summary, I think there are two main reasons for looking
further than SVN for SCM software.  1) Changesets are a big
convenience for all developers.  2) Distributed SCM lets fringe
developers benefit from a real SCM, too.

-chris

[1] http://svnbook.red-bean.com/en/1.1/ch01.html#svn-ch-1-sect-1