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 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