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

[Angela Byron]

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.

As others mentioned, https://svn.drupal.org/.../. I agree SSH 
accounts/private keys are a huge mess and would reduce our contributor 
pool to about 20 people. My #1 priority in a move to a new VCS would be 
"Encourage *more* contributors, not fewer" so I'm also -1 to complicated 
authentication schemes.

>> 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.

Fair enough. My #2 priority in a move to a new VCS is "Make Derek's life 
easier," and I thought this was more of a pain in the ass than it 
apparently is.

>> 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).

Fair enough.

>> 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.

I think a lot of this can be solved with a pointer to 
http://svnbook.red-bean.com/ which is an *excellent* and free resource 
that covers everything from "What is version control?" to "Crazy 
advanced crap you don't need to know about." This resource is much more 
comprehensive and complete than anything that we've managed to put 
together in the hundreds of hours we've spent writing docs ourselves. :\ 
And I mean this with the greatest respect, and also as someone who's put 
a bunch of elbow grease into the existing documentation, as you know.

I'm officially putting my hat into the ring for helping to upgrade 
existing docs if we move to SVN. I can't make that promise with DVCS 
because I am totally new to it, though.

>> 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.

I've been told by Sam Boyer that I am officially On Crack about the 
terrifying part, so I'll leave it to him to refute me. ;)

>> 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". ;)

No, no, no! You are *extremely* awesome and helpful! You are also just 
one guy, and seem to be the main person fielding all of the fall-out 
from using CVS. I don't like that situation, and from the exasperation 
you have communicated in the past about you being "the guy" who has to 
deal wth all the support requests, I gather that you don't either.

Every Drupal shop that I'm aware of (and we've worked with most of them) 
only uses CVS to maintain modules/themes on drupal.org. All of their 
internal and client projects happen in a SVN repository (with maybe 2% 
on something fancier like Git). So we have a tremendous amount of 
in-community knowledge about how SVN works that can be leveraged to 
off-set support requests that end up falling solely on your shoulders.

Additionally, based on my experience, #cvs has about 10 people in it. If 
I ask a question, it might literally be a day before I get an answer, if 
ever. So I end up asking in #drupal, or on the issue queue.

#svn has about 200 people in it. If I ask a question, suddenly 8 people 
chime in to answer it, give me pointers to resources for additional 
information, and also give me some tips I might not have thought of 
before. I don't need to ask in #drupal or the issue queue, because my 
problem is solved already.

So, let's try this again. ;) The compelling reasons for SVN are:

1. Passwords not passed over the wire in plain-text. :P

2. Empowerment of users to do minor things like renaming files and 
directories without bugging Derek. :D

3. Greatly increasing the pool of people that has knowledge about how to 
use and setup the revision control system we switch to, so Derek doesn't 
have to do everything. :D

4. Being able to leverage outside support materials, such as excellent 
online documentation and real-time support on IRC.

Are those better? :)
-Angie