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