On Sun, Dec 12, 1999 at 08:31:16PM -0700, Miles Nordin wrote:
> 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?

No. CVSup is only a different tool for getting updates. Greg's issue
is the same regardless of whether you use rsync, CVSup, ftp, sup...

(As long as it ends up in a local CVS repository.)

> 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'm not certain I understand the issue either, but I believe a relevant
question is whether you ever upgrade a vendor branch in your local
repository, by grabbing a newer version and importing it.

> 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,

My understanding is that CVS deals with that _very_ well. After importing
a vendor branch, you can checkout a version that has applied all of your
local changes on top of the vendor's changes - leaving only the
conflicting diffs to be fixed by hand.

> 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

As above, CVSup doesn't change the way CVS works - only how you get
the updates. What CVSup does (which it seems to do quite well, from 
my tests) is analyze the changes and efficiently send them, and make
good use of the bandwidth available, by balancing the analysis and the
updating processes.

> yet, but I don't think desupporting vendor branches is a reasonable
> solution, interim or long-term.

Greg, could you give a clear description of the difficulties you
percieve the approach will cause?

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville