[development] FAQ: Why is Drupal still using CVS when X is a much better choice?

[Sam Boyer]

So I'll be writing a bunch of responses to various items in this thread,
but let me just put this out there as a caveat: right now and for at
least the immediate future, I don't consider my newfound role as Version
Control API maintainer to include advocacy for switching d.o to any
particular RCS. In my mind, there are lots of interesting things to
think about, but I've got coding to do before it's much more than
conjecture. Personally, I can think of very legitimate arguments for &
against a) staying with CVS, b) moving to SVN, c) moving to git, hg, or
bzr. So for the moment, I'm hoping to just provide concrete information.

On Thu, 2008-07-31 at 15:01 +0100, Adrian Simmons wrote:
> Gerhard Killesreiter wrote:
> > Well, then we just can stay with CVS. IMO SVN's features aren't that
> > vastly superior to spend much effort on moving.
> That's absolutely true for Drupal core :)
> 
> But it's not true for contrib. And what we I think we all mean when we talk 
> about drupal.org moving to a different VCS is *contrib moving*.

It's true - core operates under quite a different paradigm from contrib,
and IMO the conceptual clash in the contrib paradigm v. CVS is more
pronounced than in core paradigm v. CVS.
> 
> Karoly Negyesi wrote:
>  > SVN tools are available. SVN is mature and documentation is plentiful. 
> svn > 1.5 added merge tracking for (much) better team work.

http://subversion.tigris.org/svn_1.5_releasenotes.html

Merge tracking is definitely one of the biggest single selling points of
SVN vs. CVS, although it's still orders of magnitude less powerful than
git. But IMO, that's moot unless/until someone does some pretty thorough
investigating of svn 1.5's in-practice interoperability with svn 1.4.
That means please don't regurgitate the table at the link I just posted;
we can all read, I mean how it ACTUALLY works =)

> 
> I'd add that the two most attractive features of DVCS systems - better merge 
> algorithms and offline commits - can be achieved by people using SVK in 
> conjunction with SVN.

These are indeed two very attractive features - although maybe not the
_most_ attractive, IMO - of a distributed vcs. svk also has the added
benefit of reducing the amount of overhead data that's contained in
your .svn directory, which can (especially for large projects with long
histories) end up being quite significant. But as I said before, git's
merge capabilities are in a class of their own, stemming from the fact
that git is a content-addressable filesystem.

Sort of along these lines, and partially as an additional response to
chx, another feature that's interesting in the list of items that svn
1.5 adds is 'pegs', which improve on svn:externals a bit. However,
svn:externals itself is pretty inflexible, so...


> 
> Derek Wright wrote:
>  > A) How do "we" decide which RCS to move to
> Someone could sit down with a list of our needs and do a point by point 
> analysis of what the various VCS and DVCS would provide or not but really 
> Karoly hits the nail on the head: "If we move, we move to SVN". There isn't 
> another viable choice.
> So that's A) dealt with ;)
> 
>  > D) Do we leave open the possibility that each project on d.o can choose if
>  > it wants CVS or XXX?  Do we provide multiple alternatives (svn + git?).

Multiple alternatives is a...complicated question. I don't yet know
enough to say where or how the reconciling of the different systems
would occur. My suspicion, though, is that it would be a nasty example
of the drupal community special brand of 'let's roll-our-own!' hubris to
try to reconcile them ourselves; chances are, if we were to do this,
we'd build the base with git, use its native capabilities to wrap svn,
and have the project* system speak to git.

> Someone can correct me but I think all of the DVCS possibilities can 
> integrate quite well with SVN, once you've provided SVN there's little 
> benefit to providing anything else.

Nope, no need to correct you on this one. Of hg, bzr, git, the only one
I'm not sure about providing good svn interoperability is hg. But I'm
pretty sure it should be largely the same.

> 
> 
> Just imagine this is written in a few months:
>  > C) Do we move everything at once, or do we just move core to the new
>  > thing, and leave contrib with CVS as an interim measure to prevent
>  > large-scale, simultaneous catastrophe on all sides?
> 
> Core doesn't *need* to move, there's no benefit to moving it first, it 
> doesn't even provide much of a comparison to contrib in terms of numbers of 
> commiters and their competence. I think really you'd have to select a subset 
> of contrib modules (I'm sure there'd be no shortage of volunteers) to move 
> first.
> 

I'm in general conceptual agreement here, but there are very real
questions about how we'd organize the svn repo(s) that we'd need to
answer before even considering such an experiment. There are good ways
to migrate CVS => SVN, and there are bad ways...but they all turn into
nightmares very quickly if you don't have a very clear vision of how you
organize your svn repo(s) on the other side.

cheers,

Sam