[parisc-linux] CVSy stuff

[Matthew Wilcox]

According to the folk wisdom around CVS, long-lived branches make
operations slower.  Here's some evidence:

http://mail.gnu.org/archive/html/info-cvs/2001-08/msg00939.html
http://sources.redhat.com/ml/gdb/2003-03/msg00091.html

>From this point of view, our CVS tree is practically pessimal.  We have
two long-lived, regularly-updated branches (1.1.2. and 1.).  This may
explain why CVS is taking a long time to do simple stuff that used to
not take very long at all.

I don't think that changing our linux-2.5 tree at this point is a
great idea.  Let's soldier on with it until 2.6 comes out, but I've been
thinking about a new design for our linux-2.6 tree.  Feedback extremely
welcome since I'm so far from being an SCM guru it isn't even funny.

The inspiration for this is "Wow.  Our diff vs Linus is really small now."
It's 220k; 170k of that in new files.  So our model is really "Here's a
small patch to go on top of Linus' tree."  We're no longer doing major
development in our tree and we're now able to fold changes back into
Linus' tree fairly quickly.

So how about this model...

1. -> linus
1.1 -> LINUS_260
1.2 -> LINUS_261
1.2.1 -> parisc_261
1.2.1.1 -> CVS261_PA1
1.2.1.2 -> CVS261_PA2
...
1.3 -> LINUS_262
1.3.1 -> parisc_262
1.3.1.1 -> CVS262_PA1

OK, this model clearly fits CVS' needs much better.  How about ours?
Well, it sucks that you're always developing on a branch.  It sucks for
people who're used to doing 'cvs up -A' to get to the trunk, because
they now get Linus instead of us.  It also sucks that you stay on
parisc_261 when you type "cvs up", so you have to explictly say "cvs
up -rparisc_262".

However, it doesn't have the suckitude of vendor branches, and it allows
us to reasonably use cvs diff -rlinus.  Choose your suck.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk