Switching from CVS to Subversion: test svn repo available

[Chris Shoemaker]

On Mon, Oct 24, 2005 at 12:38:35PM -0400, Stuart D. Gathman wrote:
> On Sun, 23 Oct 2005, Chris Shoemaker wrote:
> 
> > > I thought this was the main point of SVN, and the motivation for
> > > replacing CVS - that it has atomic changesets that affect many files.
> > 
> > Please see: http://subversion.tigris.org/faq.html#changesets
> > 
> > for a rather biased, but not unhelpful answer.  The frank answer is
> > that there's a *fundamental* *architectural* difference between
> > designs that use arrays of versioned trees and designs that use DAGs
> > of changesets.  I would dispute the "neither philosophy is better"
> > part.
> 
> Thanks.  That was very helpful.  So SVN does have atomic commits 
> that affect multiple files - unlike CVS.  But it internally stores versioned
> trees of file collections vs versioned trees of files for CVS vs
> collections of patches for changeset based systems.

If you'd like some more detailed info, I'd recommend:
[5] for the heart of the issue in concise terms
[6] for an good overview of the main SCM debate
[8] for an overview of SCM softwares available
[1, 2, 7] for some informative Arch vs. SVN debate
[3] for a practical perspective on SCM usage

[1] http://www.reverberate.org/computers/ArchAndSVN.html
[2] http://web.mit.edu/ghudson/thoughts/undiagnosing
[3] http://www.kdedevelopers.org/node/1028
[4] http://subversion.tigris.org/faq.html#changesets
[5] http://sourcefrog.net/weblog/software/vc/derivatives.html
[6] http://www.dwheeler.com/essays/scm.html
[7] http://web.mit.edu/ghudson/thoughts/diagnosing 
[8] http://linuxmafia.com/faq/Apps/scm.html 

> 
> > FWIW, my take on the status of this debate is that it's basically
> > over.  The systems using changesets have proven far more useful, and
> > made the versioned-trees approach seem ... well... backward.
> 
> A very important feature for me is that the repository format stills allows
> me to extract the latest version of things if it gets corrupted.  I'm
> not sure SVN meets that criterion, but CVS does.  That was the main 
> motivation for us moving from SCCS to RCS before CVS came out.

before CVS came out?!  You've .. um... been around a while, eh?  :)

> 
> > But, there are those who feel far more strongly, and are far better
> > informed than I, who make the case far better that I could.  I'd
> > suggest googling around and reading the rantings of some of the
> > designers of changeset-based systems, if you're interested in the
> > debate.
> 
> I can easily see how certain operations would be quicker and more
> natural for a changeset system.  But there are many criterion, and
> I suspect said rantings reflect different priorities than mine.
> 
> > Here's a fun link to git's author's opinion on the matter:
> > http://www.gelato.unsw.edu.au/archives/git/0504/0594.html
> 
> The main point here is that per file tracking is wrong - and I would
> agree.  Maybe I'm missing something, but from what I have read, SVN
> stores version trees of filesets rather than files - that is its motivation for
> replacing CVS.  Sure, it is storing version trees of the fileset rather
> than a collection of changesets for the fileset, but the above rant doesn't
> seem to apply to SVN.

You might agree or disagree with the premise but the rant *certainly*
applies to SVN.  The links above will explain.

-chris

> 
> -- 
> 	      Stuart D. Gathman <stuart at bmsi.com>
>     Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
> "Confutatis maledictis, flamis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial.
>