[development] CVS branch work best practices?
rob at torenware.com
Sat Feb 3 07:09:55 UTC 2007
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
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).
More information about the development