John P Cavanaugh wrote:
>
> On Thu, Jun 22, 2000 at 10:02:19AM -0500, Cameron, Steve wrote:
> >
> > > - 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)
>
.main.latest
types easy too. (. is in the central part of the three basic rows
of the QWERTY keyboard, and doesn't require a shift key.)
> > > - 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
>
And similarity with the main trunk. There's no great harm in synonyms.
> > > <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.
>
Or an explicit tag.
One thing that everybody says is to tag the base of any branch being
cut. Any more or less mechanical thing that lots of people say should
always be done is a prime candidate for automation.
> > > - 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.
>
I think we need to keep the vendor branch or equivalent functionality.
Some of the things we need to do:
- Restore earlier releases, even if the guy who installed them threw
them out
- Merge the changes we've made from the old release to the new release
- Keep track of which changes were made by the vendor and which locally
I may be slow today, but I don't see how merging the metadata is going
to accomplish all this.
> 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
>
There's an issue that I didn't see covered in the advanced merge
issue list, which is when somebody makes a change to a branch that
should not be merged forward. One example might be that a bug
has to be fixed on a branch, but it was fixed in a different way
on head, along with other changes. It shouldn't be difficult to
say "this change is only for this branch, and should not be merged".
(In my shop, we maintain merged tags for branches, and simply advance
the tag for changes that should not be propagated.)
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
