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

[Karoly Negyesi]

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

Sure. The usual configuration is that SVN is provided by an Apache module (mod_dav and mod_dav_svn) usually over HTTPS so that passwords are not sniffable and mod_authz_svn provides access control. The documentation for this is http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html . 

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

Such a rename breaks every conversion tool out there because it is, let's face it, a hack. A clever, useful hack but a hack.

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

Sure. But it kills the use "foo DRCS instead" argument. And yes it is indeed possible to grab a mirror of an SVN repo with SVK and then work locally and then push-pull to your hearts' content. 

> > 7. The SVN community is completely awesome and helpful.
> 
> Hey, what are you trying to say?  You think I'm neither awesome nor  
> helpful? ;)

You are on and they are many and yes they are helpful. And there are overlaps already.

> Not to butt heads with the contributor of the year, but I don't think  
> any of these reasons are actually "compelling". ;)

To me the compelling idea is that instead of 

cvs tag -b DRUPAL-7--1

we can say

svn copy /contributions/HEAD/modules/foo /contributions/DRUPAL-7--1/modules/foo/

It's SO much easier to explain this because this is what you have on your hard drive. The cvs tag/branch essentially means virtual directories meaning an abstraction layer which people need to comprehend. Here you have files directories and nothing virtual. (Let's not fight now the actual paths we can discuss how to lay out our repo).

I find THIS a very compelling reason. Feel free to say "nah you are full of hot air" but please tell me why.


I know someone mentioned the svn:externals support. Now, that is a MAJOR feature that might even get some money from concerned Drupal shops (hey, I can dream, can't I?) because it makes their life much easier. http://weierophinney.net/matthew/archives/132-svnexternals.html

Derek complained about SVN naive tags. I said that a solution for immutable tags is already readily available: http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/svnperms.conf.example says tags/[^/]+/ = *(add) and there we are. I can ask around for other solutions.