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
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: den 31 oktober 2004 16:47 To: Erik Andersson Cc: [EMAIL PROTECTED] Subject: 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Andersson [EMAIL PROTECTED] writes: So it's really now risk in creating the branches directly from the release version tags? There is no risk that cvs will get something confused. (The same may not be true for yourself.) Someone told me that this would be a risk for CVS to get confused. There is no risk of cvs getting confused by creating a new branch from a version tag of any kind. 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 ;-) Nah, I am giving you free advice and it is only worth what you pay for it. :-) 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. Hmmm... that was not a part of your original problem statement. Mapping versioning from one system to another can be very tricky. If you have a process worked out for you already, I'd suggest you stick to it. 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: I'll add a few remarks in-line. -- Mark 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. 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. 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. Actually, it is possible for a branch to be a decendent of another branch for cvs, not everything must be in either a two digit (main trunk) or four digit (branch off of main trunk) number space. Each branching point for creating each branch must be extracted. Yes., the point seems obvious. Each branch must be extracted in latest'n'greatest state - ie. head of each branch. Yes, for a mapping between two source control systems, this is a reasonable assumption. All branching point must be known date-wise to import into CVS in correct order.. This can be difficult to do if some branches were truely done in parallel and happened 'at the same time' in the other source control system. It also does not really help with mapping branches of branches. This can be done with some difficulty and confusion by using explicit 'cvs import -b 1.1.3 module vendor2 vendor2-version' kinds of tricks, but that way usually involves madness and years spent in therapy... You may find importing successive time-based snapshots into the new repository and using the '-d' flag to keep time and date around as in 'cvs import -d module vendor vendor-version' to be useful. Head of main trunk must be extracted. Yup. A state previous to the earliest branching point must be extracted from main trunk. Yup. It is important to beware of the fact that the last import dictates how main trunk looks in the final state. True modulo conflict resolution or local commits to the main trunk as well as the possibility of the '-X' option to import. When importing it is Vital to use the same vendor tag and a new release tag for every new import. Yes, you really don't want to lose the previous release tag by resuing it. Keep them all unique. Reusing the vendor tag is a good idea, but not necessarily a big deal if you make an oops (modulo using the -b switch). To make the import behave correctly and to get the desired result, the
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
