[development] SVN vs. CVS? (was re: CVS branch work best practices?)

[Derek Wright]

Rob Thorne wrote:
> So if we are going to start using branches more, and encouraging  
> more developers to play with tags and branch tags, it might be  
> worth studying whether or when to migrate to a more modern system.

i'll be the first to admit that CVS can be daunting to the  
untrained.  however, the entire thread about best practices for  
branching has nothing to do with CVS's failings regarding branches,  
tags, and merging.  when to branch, if/when/what to merge (and if  
not, what branch(es) to apply patches to) are generic questions that  
would face Drupal developers, no matter what revision control system  
we used.

as far as i know, the *only* viable alternative to CVS that might be  
considered for drupal development is SVN.  sadly, in spite of the  
other ways SVN improved things that CVS sucks at (basically, renaming  
files), SVN still fails to make merging branches easy.  sure, the  
syntax of the command changed from:

"cvs update -j [revision_1] -j [revision_2]"

to:

"svn merge -r [revision_1] -r [revision_2]"

but otherwise, all the same suckiness is there in both cases [1].   
getting into the details of this is OT -- my real point is that SVN  
is no paradise for revision control, especially regarding branches.   
sure, the "svn tag" operation is orders of magnitude *faster* than  
"cvs tag" in many cases, but it's no *simpler* to understand or get  
right.  and no one is complaining about wasted time while "cvs tag"  
runs, they're complaining (with some justification) about wasted time  
thinking about the revision control problems (when/why to branch/tag,  
where to apply patches, when to make releases, etc), instead of their  
Drupal code problems.

bottom line: nearly all of the confusion is being caused because of  
misunderstanding revision control concepts (and the incredibly  
complicated world Drupal has created for itself, see my other post),  
not the syntax or functionality of a specific revision control tool [2].

that said, i'm not fanatically opposed to moving Drupal development  
to a different revision control system, but it's going to take a  
*LOT* of work, and (in a year of *many* people trying) i've yet to  
hear an argument that holds any water about ways SVN would  
significantly improve our development practices to offset the very  
high cost of switching.  that said, if someone(s) wants to pay me  
enough to do all the work (and i won't make the same mistake of  
wildly under-guessing how many hours this would actually take from  
start to finish as i did with the release system) i'd be more than  
happy to do the clean separation/abstraction required so we could use  
SVN instead of CVS.  if you're serious (and have a big budget), talk  
to me off list.

thanks,
-derek

[1] http://www.dellroad.org/svnmerge/index has promise to solve some  
of these problems, and is now included in the SVN source, but it's  
still basically "contrib" as far as i can tell. :(

[2] to address Rob's other comment:

> First is the notorious "forgot -kb on cvs add" problem.

this is a non-issue in a repository with a properly configured  
CVSROOT/cvswrappers file, which thankfully, the Drupal contrib repo  
has been for at least a few months now. ;)