[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: feature request: pseudo-tag for accessing the trunk
From: |
Cameron, Steve |
Subject: |
RE: feature request: pseudo-tag for accessing the trunk |
Date: |
Wed, 19 Mar 2003 09:12:33 -0600 |
> * 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