On Thu, Jun 22, 2000 at 10:02:19AM -0500, Cameron, Steve wrote:
>
> John Cavanaugh wrote:
>
> > I havent really followed this thread much but when I looked into
> > implementing this and reviewed the code. Yikes, the HEAD stuff
> > scared the crap out of me in terms of funky things that work and
> > dont work.
> >
> > I applaud the work being done to get us there but I think this
> > is one of the points where a significant benefit can be made
> > for cvs iff we are a bit more aggressive in terms of breaking
> > backwards compatibility. I know people will probably complain
> > but I really really think we need to just bite the bullet and
> > do this right.
>
> > - Delete the whole concept of the -A option from update/checkout
>
> That would leave a hole around the area of resetting sticky options,
> ("-kb", "-kk", etc.) though "cvs update -A" might not have been the right
> thing to fill that hole in the first place.
Sticky options should probably be handled separately.
> > - Name the main trunk "main" or "trunk" and just deal with the
> > consequences of people that already have that branch name
>
> Why should we break things when it's not necessary? ".trunk"
> isn't so hard to type, you don't even have to hit "shift".
Partly for personal preference of liking main or trunk better than .trunk.
But it also allows for main.latest (which I will admit is only to facilitate
similarity with other branches)
> > - Delete the whole concept of HEAD, instead generalize it to something
> This I think can agree with.
>
> > really useful and scaleable like
> > <branchname>.latest - For the latest version on a branch
>
> ok, that's an oversimplification. but this ".latest" thing doesn't do
> anything
> that the branch tag by itself doesn't do already, is my point, so I think I
> have
> to vote against that one.
Well sort of, I included it just for similarity with branch.base
> > <branchname>.base - For the version where the branch sprouted
> I haven't thought about BASE, or what it means, at all, not one whit, so I
> haven't yet formed an opinion.
Its nice to be able to easily figure out where your branch sprouted from
using an abstract mechanism.
> > - Allow importing directly to the main branch,
> I think I agree with this, the key word being "allow".
>
> > get rid of the import branch.
> I don't agree with this. I'm not experienced with vendor
> branches, but from reading what little I have about what's
> going on there, there is a definite purpose and method to
> the madness, I believe. I don't think they can or should be gotten
> rid of. But I'm sure someone more experienced with vendor
> branches will pipe up.
>
> Perhaps there's even some reasoning related to vendor
> branches which can explain a method to the madness
> around "cvs diff" and "HEAD", though nobody has yet
> explained it to me.
The vendor branch in my opinion is a gross hack in an attempt to
mask some really deficient functionality in cvs, namely merge
meta data. If we had merge meta data we would never need the
vendor branch. Yes it would be a different model, and yes Im
going out on a limb here, but it would be a much better model.
For those interested there are some cosource.com project and funding
related to these items.
CVS Advanded Merge & Metadata Support (Currently at $3700)
http://www.cosource.com/cgi-bin/cos.pl/wish/info/187
CVS - Several Minor Feature Additions (Currently at $1250)
http://www.cosource.com/cgi-bin/cos.pl/wish/info/188
-----------------------------------------------------------------------
John Cavanaugh Agilent Technologies
R&D Program Manager 1400 Fountaingrove Pkwy
CAD Data Store Santa Rosa, CA 95403-1799
Email: [EMAIL PROTECTED] Phone: 707-577-4780
707-577-3948 (Fax)
-----------------------------------------------------------------------
Thinking is the hardest work there is, which is the probable
reason why so few engage in it.
-- Henry Ford
-----------------------------------------------------------------------
