RE: feature request: pseudo-tag for accessing the trunk

[Cameron, Steve]

> * Larry Jones <lawrence.jones@eds.com> [2003-03-18 21:18]:
> > Steve Cameron has a patch that does that (although he spells it ".trunk"
> > rather than "TRUNK"):
> 
> Now that we have different branches for development and release,
> do you see any chance that this will be committed to the dev
> branch anytime soon?
> 
> Kind regards
>    Ingolf

I haven't worked on that patch in a long time, unfortunately.
(no internet access at home anymore, which I admit
is somewhat ridiculous.)

There is a problem with the ".origin" feature and 
vendor branches (it doesn't work on vendor branches.)
I don't recall the exact details, or know how hard
it would be to fix it to work on vendor branches.

Also unfortunate, I combined the two features,
".trunk" and ".origin" into one patch, because
it was too hard to keep them separate.

I would be surprised if the sanity.sh part of the
patch still applies cleanly, as this was always prone to
throwing rejects every time somebody added a new test...
though it might not be too hard to fix.

Feel free to ask me anything about the patch, or
take it over, if any of you want to, since I don't have
much time to work on CVS anymore.

Now heading way offtopic...

Thinking a bit about _why_ i didn't keep those patches
separate.... I was using CVS, anonymous read-only access,
and doing "cvs update" to try to merge in changes,
and cvs diff -u to make the patch.  So it wasn't clear
to me how, using that method I could easily keep the patches
separate, yet still have them work together.
 
More recently, I ran across some patch management 
scripts, which, although maybe a little bit crude 
in spots, are pretty effective at allowing a set of 
patches to be kept separate, re-ordered at will, and 
ported easily from, e.g. one linux kernel tree to a newer 
one.  The scripts' author wrangles more than 1000
patches all at once this way!  I haven't tried 1000's, 
but I've done 10-20 at a time and it's pretty cool.  CVS 
doesn't have anything like that.  Of course maybe these 
are completely different problems and so different tools 
are needed.  But for me, playing around with those patch 
scripts underlined how nice some kind of changeset management 
would be for CVS.  Not that I have some concrete idea about 
how it should work.  Well,  I'm thoroughly off topic now, 
so I'll shut up, but in case you want to know what I mean, see: 
http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.10/
(which are not guaranteed bug free, by the way, so don't
blame me if it trashes your patch set, but maybe somebody 
will find as useful as I have.)

-- steve