On Sun, 12 Dec 1999, Greg A. Woods wrote:

> As I said there's a big problem with using CVS on modules that are
> vendor branched and locally branched from the trunk.  It not only cannot
> do what it was designed to do (local conflict detection), but it also
> gets in the way because local branches require all vendor revisions to
> be pulled over to the trunk before a local branch is created.

You are talking about CVSup, right?  that is, you're using it to maintain
local branches, no?

I confess that I don't understand what you're talking about, and that my
limited CVS knowledge is surely part of it.  But, I have no problems with
my local modifications using sup & CVS.

I know CVSup is supposed to do a different (more complete) job with local
branches, and faster, too, and probably i will end up using it someday,
too.  But isn't the real problem simply that CVS is fired for not dealing
with (or admitting the existence of) ``local'' branches?  And that CVSup,
for all its supposed glory and usefulness, still doesn't adequately work
around this problem?  It's sad that local branches don't work perfectly
yet, but I don't think desupporting vendor branches is a reasonable
solution, interim or long-term.

Given CVS's importance to a lot of highly public projects these days, I
expect someone to ``pull an egcs'' with it soon, and evcs will probably
add local branches before anything else.  I know this doesn't solve your
problem, but when we know we're dealing with a kludge to begin with the
decision process has to be different--for one thing, there should be an
even stronger resistance to 2' kludge-fixing kludges than there is to mere
1' kludges.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US