[ On Sunday, December 12, 1999 at 20:31:16 (-0700), Miles Nordin wrote: ]
> Subject: Re: src/dist is a *bad* idea
>
> You are talking about CVSup, right?  that is, you're using it to maintain
> local branches, no?

Nope.  And actually I would strongly recommend *against* people creating
local branches in a CVSuped repository.  Infinite confusion could result
(though as I understand it CVSup goes to some length to work around the
problems such actions present, but unfortunately it's a messy problem).

What CVSup user should do if they want to actually do something to the
code in a CVSuped repository is just apply local tags (perhaps with
careful manual adjustments to back out recent bugs or undesirable
features, etc.) and use those tags with "cvs export" to create a local
``release'' which can be imported into a local private repository or
whatever.

This way there's also really no difference between CVSup, sup, ftp, or
rsync, or whatever with how one deals with the third party code.  CVSup
simply provides a local copy of the vendor's repository for handy
reference and provides a more efficient and convenient way of marking
which vendor revisions were taken for the local release.

> Given CVS's importance to a lot of highly public projects these days, I
> expect someone to ``pull an egcs'' with it soon, 

Maybe, but I doubt it, at least not for a while.  I almost did that
myself, but I didn't have the time or resources to do so.  Recent
changes to the primary forces behind CVS maintenance make such a split
even less likely.  As it is I never got further than creating my own
working branch in the CVS repository and bashing about on it in there.

> and evcs will probably
> add local branches before anything else.

This I can almost guarantee won't happen soon, if ever.  It's not an
easy problem to solve.  I've spent a lot of personal time working on it
myself and I've yet to discover an elegant and simple way of solving it.
The "hard" solutions require intensive book keeping (which would of
course be the repository's job) and a *lot* of extra manual work.

The other factor is that there are better ways of managing the most
common problems which present this need for multiple vendor branches and
indeed there's a product on the very near horizon that will hopefully
show that at least one of those different ways is vastly superiour.
Unfortunately that scheme is mostly incompatible with the way CVS works
from the ground up.  Fortunately it's likely that other source
management tools may be able to mimic it once they see how well it works
in practice.  The product I'm speaking about of course is Larry McVoy's
BitKeeper.

If any split in CVS development does happen it'll be the NT and WWW
weenies branching off a non-concurrent-editing tool that'll handle the
binary file formats they incessantly insist on using.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>