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

[Larry Garfield]

A distributed VCS would really only offer a benefit if it gets integrated into our development workflow.  Were we to instead of having one single maintainer for all of Drupal (or a given version) have subsystem maintainers with partial commit access, the way the Linux kernel does, that would be much easier with a DVCS than with CVS or SVN.  (It's probably something we should consider in the near future.)  A DVCS could also potentially make major overhauls like FAPI, the theme system, or the new Database API easier to manage as we wouldn't need external svn repositories to coordinate that work.  (That has been a sizable pain in the butt for the Database API rewrite.)

All of those would require drastic changes to the Way We Work(tm).  Unless we are going to make such a change to our development workflow, a DVCS doesn't offer much benefit.  

Several projects seem to have addressed that issue with, as others have noted, an SVN core repository with a git bridge.  I believe PHP itself is planning to do so.  That gives a "traditional" VCS for most people while allowing the 5% of users who would actually benefit from a DVCS to sorta use it, although not with all of its benefits.  Were we to move off of CVS, at this point that would be my recommendation.

Another advantage of svn over CVS that I don't think anyone has mentioned is that, as far as I am aware, it is much easier to do fancy external linking with SVN than CVS.  If managed properly, that could be a boon for Drupal companies (like Palantir, where we have been discussing this exact problem) who want to tie their source management more tightly to Drupal's.  Let's face it, checking out from CVS into an SVN repository is a hack, and Drupal abhors hacks. :-)

--Larry Garfield

On Thu, 31 Jul 2008 09:51:28 -0700, Michael Prasuhn <mike at mikeyp.net> wrote:
> (This post is directed as much for developers out there, and companies
> with their own process than it is at d.o)
> 
> I've recently been through a similar process with the company I'm with
> now, and come to the same conclusion regarding SVN. While I prefer to
> do my own personal projects in other systems, SVN is the lowest common
> denominator of VCS that I could find. I am the first full time
> developer at my company, and the other employees must have a GUI or
> they can't use VCS.  We are currently stuck in a mix of another DVCS
> that is not working well, as there is not enough documentation, and
> neither I nor the consultant who previously set this up for them are
> experienced in it, rather the consultant wanted to be cutting edge and
> move to a distributed system.
> 
> The other major complaint I have at this point, is that moving to a
> specific DVCS has actually limited workflow options. Previous
> companies/clients which used SVN actually had more options since
> almost every major DVCS (hg/git/bzr) has an SVN plugin to allow
> directly working with a SVN repository. This allows each developer to
> use the methodologies/workflow that best suits them, for their
> development.
> 
> -Mike
> 
> On Jul 31, 2008, at 3:44 AM, Karoly Negyesi wrote:
> 
>> If we move, we move to SVN. My team, consisting of mostly pretty
>> good coders tried a few distributed RCSes and given this experience
>> I am now vehemently against any DRCS. The concepts are way too heavy
>> and the utilities are not ready. Most of these systems are not that
>> mature thus any docs from 1-2 years ago are worthless thus
>> documentation is not much. When I was for a DRCS in 2005/2006 I was
>> a naive greenhorn sorry for the ruckus I caused then, I now know
>> better.
>>
>> And back to Drupal contrib, at least with a central repo you can
>> have some central control trying to keep order but with a DRCS all
>> bets are off. Check contrib CVS root for all the crap our CVS
>> challenged contributors add there and think what would ensue with a
>> DRCS.
>>
>> It's highly debatable that the most serious of our problems, namely
>> understanding RCS would be solved by any DRCS. You sure want to
>> explain multiple heads for one or patch algebra for another? How
>> does 140+ commands sound (and then some has one or two superb
>> powerful switches...) This is a terrible mess.
>>
>> Now, with SVN we wll need a script to stop tagged things from being
>> changed because they are not immutable as they were in CVS -- but
>> this is readily available and this is the only problem I am aware
>> of. SVN concepts are mapping much better to reality -- one dir per
>> branch/tag. Makes it (much) easier to understand. You already keep a
>> separate directory for your branches so that's how the repository
>> looks like, easy! Thus it _will_ solve some problems -- another
>> problem with DRCS that it does nto solve the problems we have :) SVN
>> tools are available. SVN is mature and documentation is plentiful.
>> svn 1.5 added merge tracking for (much) better team work.
>>
>> Feature foo and bar might be unavailable for SVN but I can not
>> care , we need something that we, we all of the Drupal community can
>> use.
>>
>> Once the reboot of my life is complete (read: September) I will
>> rejoin the moving effort and help.
> 
> __________________
> Michael Prasuhn
> mike at mikeyp.net
> http://mikeyp.net
> 503.488.5433
> 714.356.0168 cell
> 949.200.7670 fax