Re: Import and merge into branch
[ On Sunday, October 31, 2004 at 20:59:56 (-0800), Mark D. Baushke wrote: ] Subject: Re: Import and merge into branch There is no risk of cvs getting confused by creating a new branch from a version tag of any kind. That's not exactly true in all cases. ;-) CVS will get confused if a new normal branch is created (i.e. with cvs tag) in a module created with cvs import and then another subsequent import is done and an attempt is made to merge it. CVS vendor branches do not co-exist well with normal CVS branches due to the optimizations used and due to the hackish default branch magic used for vendor branches. As you know the mechanics are rather complex to work through but suffice it to say that newly imported changes can suddenly appear in the wrong places when vendor branches and normal branches are mixed. I see this too regularly in the NetBSD repository where I do all my local work in a directory that was checked out from a normal branch and where sometimes cvs import is used imporoperly to update third-party code and where local changes are also made on the trunk of that third party code. Of course as you suggest below it is also true that even just with the normal vendor branch management tactics, i.e. even when no normal branches exist, that the whole module in the repository is in an inconsistent state between the time the import is started and the time the commit of the merge of new vendor changes to the trunk of locally changed files is completed. Future direction change: The cvs 1.12.10 (not yet released) will have a -X option to import that allows you to import and not be visible on the main trunk by default. Version 1.1 exists (it always needs to be created) and version 1.1.1.1 is the first imported version, then with -X a dead 1.2 version is created right away. This protects the main trunk from imports that might confuse it and allows you to merge vendor files into the main trunk in a controlled commit in conjunction with other mainline files. I don't think that's really going to help much in the case where normal changes also exist, but I've not thought it through entirely. I.e. I think one would also have to get rid of the reliance of the default branch hack in vendor branched modules in order to make it work as safely as possible. I.e. the right thing to do would be to completely eliminate the stupid 1.1.1 branch junk and to always create and treat the vendor branch as a normal branch and to always do a full commit of new vendor releases to that branch and then to a normal, manual, merge of the changes on the vendor's branch to the, or to each, local branch as necessary. Such a change would of course be incompatible with existing repositories containing the current style vendor-branched modules. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import and merge into branch
OK, thanks a lot for your reply, but wouldn't this create the branch from the magic import branch? Is that really ok? Is there no danger in creating branches from the revisions in a magic branch? Best Regards / Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: den 29 oktober 2004 18:15 To: Erik Andersson Cc: [EMAIL PROTECTED] Subject: Re: Import and merge into branch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Assuming you did cvs import module VENDOR VENDOR-VERSION then something like this: cvs rtag -b -r VENDOR-VERSION newbranch module cvs checkout -r newbranch module should get what you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBgmyh3x41pRYZE/gRAnpJAKCe/kOFLGyMGQlFiiKH7rpNNFlSawCdEO54 Y37ySHXbJrOLgcioz92Csqw= =+vFW -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import and merge into branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: OK, thanks a lot for your reply, but wouldn't this create the branch from the magic import branch? If you mean that newbranch will have a magic version number of something like 1.1.1.1.0.2 and commits to it will look like 1.1.1.1.2.1, then yes. Is that really ok? Sure, I do it all the time. Is there no danger in creating branches from the revisions in a magic branch? The vendor branch is not a magic branch (unless you did something very odd when you did the import with the -b option?), it is branch 1.1.1 and you would be maging a 'magic branch' from the latest VENDOR-VERSION tag which is not itself a branch. -- Mark Best Regards / Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: den 29 oktober 2004 18:15 To: Erik Andersson Cc: [EMAIL PROTECTED] Subject: Re: Import and merge into branch Erik Andersson [EMAIL PROTECTED] writes: I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Assuming you did cvs import module VENDOR VENDOR-VERSION then something like this: cvs rtag -b -r VENDOR-VERSION newbranch module cvs checkout -r newbranch module should get what you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBhQkF3x41pRYZE/gRAu/sAKDMgISDuYEyiS2LPO91cSXTJOYz2QCfd8hf C4y19fASes/ETRtLxqVllq8= =jDtA -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import and merge into branch
Thanks a lot again!! So it's really now risk in creating the branches directly from the release version tags? Someone told me that this would be a risk for CVS to get confused. We have already spent to much time trying to fix this so I really need to get this things straighten out before I go talk to my boss.. I would also appreciate other peoples say, although I think I really should trust Mark ;-) What we really wanted to do was to go from another versioning system to CVS and and for this we used the import. We have a lot of projects working across eachother and often working with the same files etc. This is what's was sent to me and this is from what I am to understand that this is the way for us to go: CVS Guidelines. These guidelines are written on current experience with larges projects having many parallel branches of the same source in various states. Projects not having so much going on in parallel can get much easier off than what these guidelines states. Converting from another project If conversion from another versioning system is needed before using CVS, then care should be taken if conversion must maintain existing current development and/or multiple stages/milestones from the old versioning system. CVS has a sort of odd way of using revision numbers when importing. First revision is 1.1.1.1 and Not 1.1. However, when modifying a file in main trunk the first change on that file will get revision 1.2! This is quite important to notice as it is needed when changing to use CVS from another versioning system at a time where active branches still exists. The following images/filesets are absolutely necessary when changing to CVS and not loosing active states. The assumption is that all branches are decendents of main trunk and that they are in parallel. Each branching point for creating each branch must be extracted. Each branch must be extracted in latest'n'greatest state - ie. head of each branch. All branching point must be known date-wise to import into CVS in correct order.. Head of main trunk must be extracted. A state previous to the earliest branching point must be extracted from main trunk. It is important to beware of the fact that the last import dictates how main trunk looks in the final state. When importing it is Vital to use the same vendor tag and a new release tag for every new import. To make the import behave correctly and to get the desired result, the following way of building the repository could be used: Import what is going to be head of main trunk. Import each branching point in reverse date order. Import each branch-head. Import the comming ancestor (the oldest main trunk state). Force commit of main trunkt to set all revisions to 1.2. Merge differences from imports to main trunk to create each branching point in main trunk. Remeber to set a tag after each merge for indentification. Branch of each branching point, checkout each branch and make a recursive force commit. This gives revisions like 1.X.2.1 for all files, where X is the version from main trunk. For each branch merge differences from import to create head of branch. For main trunk merge the last for setting the real head state. It is a lot of imports and merges, but you should end up with something like: Main +---Import Head-of-main (1) || | Import Branching-point-2 (2) | Import Branching-point-1 (3) | Import Branch-head-1 (4) | Import Branch-head-2 (5) || | Import Ancestor (6) | (A) -- forced commit giving state of (6) | (B) -- merge to branching-point-1 (-j ancestor -j branching-point-1) | \ | \ Branching to branch-1 | | | Forced commit + set start tag | | | Branch-1 head -- Merge to branch-2 head (-j branching-point-1 -j branch-head-1) | | (C) -- merge to branching-point-2 (-j branching-point-1 -j branching-point-2) | \ | \ Branching to branch-2 | | | Forced commit + set start tag | | | Branch-2 head -- Merge to branch-2 head (-j branching-point-2 -j branch-head-2) | | (D) -- merge to Head-of-main (-j branching-point-2 -j head-of-main) The resulting state (D) should be the production state. If this setup should be carried out to create the branches according to the branching strategy below, then a little further branching and forced commits are necessary, but it is not especially complicated. Branching strategy Branches should normally reference the current state of a given environment. In this context with larger projects it gives: production | +---Test | +---Development This mostly when a lot of developers are involved. Having a full environment with the above structure, then it becomes almost vital
Re: Import and merge into branch
, the following way of building the repository could be used: Import what is going to be head of main trunk. Good idea. Import each branching point in reverse date order. Reasonable. Import each branch-head. Hmmm... possibly, depending on what is meant by this. Import the comming ancestor (the oldest main trunk state). Yup. Force commit of main trunkt to set all revisions to 1.2. See use of the -X option above... Merge differences from imports to main trunk to create each branching point in main trunk. Remeber to set a tag after each merge for indentification. Yup. Branch of each branching point, checkout each branch and make a recursive force commit. This gives revisions like 1.X.2.1 for all files, where X is the version from main trunk. I am not sure this is necessarily reasonable or correct or desirable. For each branch merge differences from import to create head of branch. For main trunk merge the last for setting the real head state. It is a lot of imports and merges, but you should end up with something like: Main +---Import Head-of-main (1) || | Import Branching-point-2 (2) | Import Branching-point-1 (3) | Import Branch-head-1 (4) | Import Branch-head-2 (5) || | Import Ancestor (6) | (A) -- forced commit giving state of (6) | (B) -- merge to branching-point-1 (-j ancestor -j branching-point-1) | \ | \ Branching to branch-1 | | | Forced commit + set start tag | | | Branch-1 head -- Merge to branch-2 head (-j branching-point-1 -j branch-head-1) | | (C) -- merge to branching-point-2 (-j branching-point-1 -j branching-point-2) | \ | \ Branching to branch-2 | | | Forced commit + set start tag | | | Branch-2 head -- Merge to branch-2 head (-j branching-point-2 -j branch-head-2) | | (D) -- merge to Head-of-main (-j branching-point-2 -j head-of-main) The resulting state (D) should be the production state. If this setup should be carried out to create the branches according to the branching strategy below, then a little further branching and forced commits are necessary, but it is not especially complicated. Branching strategy Branches should normally reference the current state of a given environment. In this context with larger projects it gives: production | +---Test | +---Development This mostly when a lot of developers are involved. Having a full environment with the above structure, then it becomes almost vital that CVS is used correctly and that CVS is somewhat prohibited from making errors when merging. This can be done by forcing a commit on ALL files whenever creating a new branch. Production will always be carried in the main trunk of CVS and everything else will be branched out from there. Taking the above into consideration, then when making a development branch, which must be applied to Test before it goes to production, then when making the Test branch, all files must be forced committed to make the revisions correct before making the development branch. The issue here is if this is not done, then the development branch will be a parallel branch to the Test branch, which is not what you want. The reason is that CVS does not assign a new revision to a file when creating a branch - it either needs a change or a forced commit. As most environments also need bugfixing, then a branch for that would usually come in very handy. My resulting branching structure thus becomes to be like this: Production | +---prod-bugfix | +---Test | +---test-bugfix || |+---patchXX |+--- | +---Development-shared | +---ProjectA +---ProjectB +--- Notes: The normal bugfix branch would be test-bugfix as prod-bugfix is only to be used for emergencies. The patchXX branches could be simulated using pre/post tags in the test-bugfix branch, which gives the endpoints for merges. Best Regards / Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBhcLM3x41pRYZE/gRAvwoAKCp8SMaPNr34Uy86zPHX5AUjxAhowCg17da pQeak59XvMhsY2XWyhwHP3I= =Js6v -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Import and merge into branch
Hi I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Best Regards / Erik CIP Development Environments, [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import and merge into branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: I messed up and need to to a fresh import and then make a branch contain all from that import. How do I do? I only want that code in the branch and not into main.. Can I use the original branch and somehow merge this into the branch? Please help me out!! Assuming you did cvs import module VENDOR VENDOR-VERSION then something like this: cvs rtag -b -r VENDOR-VERSION newbranch module cvs checkout -r newbranch module should get what you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBgmyh3x41pRYZE/gRAnpJAKCe/kOFLGyMGQlFiiKH7rpNNFlSawCdEO54 Y37ySHXbJrOLgcioz92Csqw= =+vFW -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
