Re: Branching in a vendor branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jay, I believe you want to use cvs 1.12.9.1 as taken from the feature branch of the cvs.cvshome.org repository. It has a new feature for import which is the -X switch to make sure that vendor imports do not show up on the main trunk. See the thread http://lists.gnu.org/archive/html/bug-cvs/2004-06/msg00173.html for more details. To download a copy of the top-of-tree feature branch, you will need to register with the site, login to the site, go to the page: https://ccvs.cvshome.org/servlets/ProjectSource and follow directions for how to download the sources. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBI5sJ3x41pRYZE/gRAoxUAKCqVyjytlf/P6OXdT6eKzfzLMBVwgCfWTGU d+unaOJ2njyvBklSjMB+TFA= =BXsr -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branching in a vendor branch
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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branching in a vendor branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] [EMAIL PROTECTED] writes: 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. Huh? You CAN specify the '-b 1.1.3' value if you need it. This command: cvs import -b 1.1.3 repository-module vendor-tag release-tags... should work correctly. If not, file a bug report. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBIn0r3x41pRYZE/gRAkT3AKDCYtE/E7g9IRWYlTiKJIhdh23OkgCglrRo i6bZaXRBNvNjYq+TqxV182o= =qPM9 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Branching in a vendor branch
I have a project in CVS which is a feature enhancement patch to an open source project. My feature enhanced code is checked into the trunk. Each major release of the open source project is checked into the CVS vendor branch. I have been developing successfully in this manner for quite some time now. 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 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. Thanks for any suggestions you may have, Adam ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branching in a vendor branch
On Mon, Aug 16, 2004 at 06:22:33PM -0700, [EMAIL PROTECTED] wrote:
I have a project in CVS which is a feature enhancement patch to an
open source project. My feature enhanced code is checked into the
trunk. Each major release of the open source project is checked into
the CVS vendor branch. I have been developing successfully in this
manner for quite some time now.
I do that too.
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.
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. :-)
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com
The most exhausting thing in life is being insincere.
- Anne Morrow Lindbergh {American Author}
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
