Re: Branching in a vendor branch

[address@hidden]

On Mon, 16 Aug 2004, Doug Lee wrote:

> > What has happened that is different that I don't understand how to
> > handle is the following.  The open source project had to create a security
> > patch to the last production release.  A branch was created off the last
> > release tag, and the changes for the security patch were stored in 
> > that branch.  This is where I am a bit lost.  I don't see a direct
> > way to create a branch within my vendor branch so I can track this security
> > patch release.
> 
> I don't see why you can't, from a sandbox containing a checkout of the
> last vendor branch import (which, of course being a vendor import,
> will have a tag and is therefore easy to check out again):
> 
> cvs tag -b vendor_release3_security     # to create the branch point
> cvs update -r vendor_release3_security  # to switch the sandbox onto the 
> branch
> # copy in the security patch version, which will update files and may add 
> some new ones
> # remove any files not present in the security update
> # use cvs add and cvs remove to effect those changes in CVS
> cvs commit
> cvs tag vendor_release3_security1
> 
> This method won't give you the ability to use cvs import to get new
> security-branch versions, but it will give you what you want otherwise.
> Of course your tag naming conventions may differ from my example.


It is too bad you cannot specify an import with -b using a symbolic
branch tag.  Semantically that seems consistent with the intent
of -b1.1.3, for example. 

Doing what you suggest seems like that will work.  I think I will give a go
at writing a script that does this, since it would be easy to skip a step
when doing this all by hand.


> > 
> > I do see in the CVS documentation you can have multiple vendor branches,
> > like the RED and BLUE team examples discussed in 13.6 here:
> >   https://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_13.html#SEC104
> > 
> > This is not the same as creating a branch within a vendor branch.  However,
> > I will use this mechanism to track the security patch release in my
> > situation, unless someone here can describe a better way to accomplish what
> > I am trying so solve.
> 
> I think that would work if the security branch doesn't get a lot of
> updates, but it would get pretty confusing otherwise, and either way I
> bet it would make for some pretty bizarre internal deltas. :-)


The other problem I see with this solution is you can easily enough "loose"
the intended relationship between the new vendor branch and the original
vendor branch, and become hopelessly confused as to what happened a year
after the second vendor branch was created.  I think it is better the patch
branch actually be created off of the vendor branch.
---
Adam Bernstein / no6_at_pobox.com
Key fingerprint =  E1 91 49 4C 24 18 E2 04  7A D3 78 A8 86 A9 7C 38