Re: adding on branch

[Mark D. Baushke]

Stefan Monnier <monnier+gnu.cvs.bug/news/@rum.cs.yale.edu> writes:

> >> 1 - create a branch B
> >> 2 - import a new vendor version with a new file F (gets rev 1.1.1.1)
> >> 3 - add a new file F on branch B
> >> 
> >> now the HEAD of the trunk for file F is 1.1.1.1 (it's magical).
> >> But if switch steps 2 and 3, you instead end up with a dead head
> >> for file F on the trunk.
> >> 
> >> Why should the order of 2 and 3 make any difference to the user ?
> >  
> > Why should they be the same?
> 
> Because activity on a branch should not interfere with activity on
> the trunk, maybe ?
> 
> > Apparently the local site has local changes cooking that might well need
> > to be merged into the top-level or branched off of the top-level if the
> > order is reversed.
> 
> Huh?  There's no apparently-anything in the example above.  There's just
> someone using a branch and someone else using the vendor-branch (and the
> trunk).  You can't outguess them.  The guy doing the import might not even
> know that someone else is playing around on branch B.
> 
> > It sounds like you are proposing that the vendor branch be chosen based
> > on bringing in a new dead version on top of an existing dead version
> 
> Not at all.  I just want the above example to give me the same behavior
> independently from the timing of 2 and 3.  That probably means that
> if the import see a dead-revision 1.1 it should still set the default
> branch to 1.1.1, as it does when the RCS didn't exist at all beforehand.

Hmmm.... one problem is to figure out how things should be setup to do
merge operations between the mainline trunk and your development branch.

> > For example,
> 
> >   1.1 is dead
> >   1.1.2.17 is the active version on the branch
> >   <import>
> >   1.2 is dead, but copy of 1.2.1.1
> >   1.2.1 is the vendor branch
> >   1.2.1.1 is the first version on the vendor branch
> 
> I don't see why you'd want/need a dead 1.2, but you might be right about it,
> I wouldn't know.  OTOH you don't mention the state of the default branch
> (i.e. the "cvs admin -b" thingy used by the magic branch support) which I'd
> want to be "1.2.0.1" in the above scenario.

Actually, I suspect the default branch would need to be 1.2.1 in this case.
Vendor branches are separate from cvs magic branches.
 
> Also since the default branch now points to a live branch, the trunk is not
> dead anymore and the file should be moved out of the Attic.

Sure. Actually, there has been some talk of just removing the Attic
optimization for the mainline. It was needed before cvs was taught about
the dead state, but it is not really needed these days.
 
> > If so, doesn't this violate the principle of least astonishment that
> > the local site may have desirable code in the 1.1.0.2 branch they
> > created that should be merged into the trunk if that code goes live?
> 
> I think that's due to your revision 1.2 above.  I'm not sure why you needed
> to do that.

It is for dealing with merger issues... that is still the hardest
problem. Finding the correct greatest common ancestor version.

        -- Mark