[development] CVS branch work best practices?

[Rob Thorne]

Bèr Kessels wrote:
> * People mentioned in several occasions that CVS is difficult stuff. I think 
> this is a known fact for many, but it is a very important fact. Dries talked 
> about 'keeping code accessible for new developers' often. Well, Drupal code 
> may be that, I think the 'required' CVS skills to actually use/contribute the 
> work defeat a lot of that accessible code. Just a thing to remember, IMO. 
>   
I don't want to start too much of an argument about version control 
systems and software (even though, um, the occasional flamewar is fun), 
but Bèr  is raising some issues that especially apply to CVS, which has 
not had a major revision since I started working with it almost 10 years 
ago.

There are several kinds of things that get screwed up in CVS more than 
in newer systems.  First is the notorious "forgot -kb  on  cvs add"  
problem.   But  tags and branches  are  right  up there.   I personally 
think that  rather than a talented human programmer,  an evil demon was 
actually tasked with designing CVS's branch system.  It's a mess, and 
just about every popular system created since has come up with a less 
error prone,  easier to understand solution.  Most of these solutions 
are more efficient to boot, and do a better job in preserving history on 
a file as its name is changed or when the file is merged (in some systems).

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.

There are at least 3 candidates for this, and most of you know what they 
are, so I'm not going to name them.  Any of these systems might be a 
better choice than CVS.  I appreciate that tremendous work (especially 
in writing custom modules and automation) has been invested by folks 
like killes into the current CVS set up,  so I know that such a change 
would need a very long lead time.  But since this is very early in 
Drupal 6 time,  it might be worth putting together a plan that might 
start a transition after Drupal 6 is final and has settled down, so that 
by the time Drupal 7 is ready,  we can transition to a more modern system.

My 2 cents (or 2 bits, even).

Rob