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@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@mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax