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

Sam Boyer drupal at samboyer.org
Thu Jul 31 17:50:49 UTC 2008


On Thu, 2008-07-31 at 10:46 -0700, Derek Wright wrote:
> On Jul 31, 2008, at 9:40 AM, Angela Byron wrote:
> 
> > 1. Security. pserver authentication is horribly, horribly insecure.
> 
> I think the security problems will be just as bad with SVN given the  
> OSUOSL infrastructure.  There's a way to do CVS securely (over ssh),  
> which is basically equivalent to what we'd have to do to actually  
> make SVN secure (as far as I know), but the OSUOSL side of this  
> question has been "won't fixed" because it would involve giving  
> (extremely limited) shell access to every CVS account holder:
> 
> http://drupal.org/node/199412
> 
> I'll admit I haven't closely studied SVN's various security models,  
> so I could be wrong about this, but on the surface, I think this  
> particular argument is a red herring, since we couldn't configure SVN  
> any more securely than we can configure CVS.  If anyone can provide a  
> link to a clear document explaining how to configure SVN more  
> securely than pserver if you don't actually have accounts and ssh  
> keys for everyone, please do so.

So let me quickly just respond here to say that, in fact, SVN is almost
terrifyingly easy to set up securely using SSH. No need for shell
accounts per user. Obviously using ssh keys means that we'd need to
_get_ those public keys from people in the first place, and doing so
would also be a very real change for all contributors: either you learn
SSH, or you can't contribute to drupal.

> 
> 
> > 2. The ability to rename and move files, retaining version history,  
> > without having to post a support request to the repository  
> > maintainers.
> 
> Yeah, this is a minor pain in the ass (my ass, to be precise, since I  
> don't think anyone else has ever fielded one of the cvs_rename  
> issues).  But, I've been documenting the process in various issues  
> and hopefully others could pick up some of this (relatively small, in  
> the scheme of things) support load.
> 
> 
> > 3. The ability to remove directories without having to post a  
> > support request to the repository maintainers.
> 
> 
> The people who botch this aren't the ones who notice and fix it,  
> anyway.  Usually killes or I find the cruft strewn about various  
> places in the contributions repo directory tree that don't belong and  
> we clean it up.  Sometimes someone else points it out first, but even  
> if we had a different VCS, cleaning up stuff like this would take the  
> intervention of a repository admin (because of access control  
> reasons, if nothing else).
> 
> 
> > 4. Much, much more intuitive commands.
> 
> This doesn't matter if people already know the CVS commands.  If they  
> don't, we've got handouts, handbooks, screencasts, DrupalCon talks,  
> off-site writeups, and more, explaining what they need to know...   
> And, as Earl pointed out, the most important commands for tagging and  
> branching are arguably much less intuitive, and those are the ones  
> people seem to have the most trouble with.
> 
> 
> 5. answered in another message...
> 
> 
> > 6. I don't know a lot about SVK, but if SVK can be combined with  
> > SVN to provide the advantages of DRCS for advanced users, without  
> > reducing our pool of contributors to like 5%, then cool. ;)
> 
> Agreed.  This is about the only feature I'd actually be psyched  
> about.  And, making the ~10% of developers that would be psyched  
> about this happy doesn't outweigh the huge costs (and the "terrifies  
> the living Hell out of me" problem of SVN's notion of tags) of a switch.
> 
> 
> > 7. The SVN community is completely awesome and helpful.
> 
> Hey, what are you trying to say?  You think I'm neither awesome nor  
> helpful? ;)
> 
> Not to butt heads with the contributor of the year, but I don't think  
> any of these reasons are actually "compelling". ;)
> 
> Cheers,
> -Derek (dww)
> 
> 
> 



More information about the development mailing list