Hi Gerry: [I'm putting this on the list in case someone else would like to know --thank, tom]
> From: Shaw, Gerry [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 12:23 PM > > In your last email you seemed in favor with the /nant/master and > /nant/version/0.7/ type cvs repository structure but in your > earlier message > you seemed against it. I am against it. > I must confess that I've never done a branch in CVS. Is it > very different > from Perforce? Have you used Perforce branching? I have not used Perforce, but I hear many good things about it from people like Brad Appleton. A lot of SCM people that have used Clear Case from Rational like Perforce. > If I want to work on a master and a couple of stable branches > (to fix bugs) > using CVS how would I do that? CVS works by maintaining a directory structure of RCS files. You find this in the CVS repository. In CVS, there are two basic tag types: Branch tags, and regular. Every CVS project has a hidden branch tag called HEAD. This is your mainline development branch. HEAD always tracks the tip of the mainline; so "cvs co nant" does the same thing as "cvs co -r HEAD nant" since HEAD is the default branch. Now let's say I create a release, so I make a regular tag in my working space. "cvs tag nant-1_0-build-1 *" This allows me to go to any empty directory and check out this exact source collection at anytime down the line. "mkdir temp; cvs co -r nant-1_0-build-1 nant" This allows me to reproduce a build at anytime as long as nobody goes and force changes the tag. "cvs tag -F nant-1_0-build-1 *" Now if you went through 8 development builds and build 8 becomes the one that passed QA controls and is released to the public. I can then create a maintenance branch off of build 8. "cvs rtag -b -r nant-1_0-build-8 nant--1_0--main--br nant" where: rtag -> work on repository instead of current workspace -b -> make this a branch tag instead of a regular one -r <tag> -> reference this existing tag <br-tag> -> create this branch tag <module> -> on this defined CVS module You can do the same thing by, "mkdir temp; cvs co -r nant-1_0-build-8; cvs tag -b nant--1_0--main--br *" Now I can go to the root of my workspaces and check out both the mainline "HEAD" branch and the maintenance branch. "mkdir ws; mkdir mainline; cd mainline; cvs co nant; cd ..; mkdir 1.0; cd 1.0; cvs co -r nant--1_0--main--br nant; cd ..;" The main difference between regular and branch tags: 1. Branch tags always track the tip of the branch they define. 2. You can check in on a branch tag. 3. Regular tags are fixed. 4. You can not check in to a regular tag reference. When you create a branch in SourceSafe, it copies the entire project structure into various different parts of it's repository. The result is that you quickly bloat the repository when you do alot of branching. When you create a branch in CVS, it just uses RCS version numbering to track the branches within the target file. Thus, while the underlying RCS file grows with each branch you do, there is not a whole sale copy of the repository. The result of this is that my development workspace will look similar to what you are proposing. However, the repository will remain relatively small and not require more and more hard drive space for the repository. The reason that you use branches for maintenance only and not for forward development is because CVS slows to a crawl when the size of the branch becomes huge. The same thing happens the further you branch from the HEAD branch. This is one reason that change-sets haven't really caught on when using a CVS repository. Change-Sets is another thing that I think Perforce has that is tedious to implement in CVS. Now say you have fixed a couple of bugs on a maintenance branch and you want to roll your changes back into the mainline of development. The strictest merge algorithm that I have seen involves three regular tags: 1. Checkout the maintenance branch and fix the bugs. 2. Check your fixes in on this branch. 3. Create a regular tag on this branch to represent the merge point. eg: cvs tag nant--1_0--main--mp-20020814T1400 * 4. Checkout the mainline branch. 5. Create a regular tag on this branch to represent the before picture. eg: cvs tag nant--1_0--main--mp-20020814T1400-before * 6. Merge the delta from the maintenance branch onto the mainline. eg: cvs up -j nant--1_0--main--base -j nant--1_0--main--mp-20020814T1400 * 7. Correct conflicts and do a successful build. 8. Create a regular tag on this branch to represent the after picture. eg: cvs tag nant--1_0--main--mp-20020814T1400-after * Now you have the ability to roll back to before and after the merge operation. One note: On merge operations, only go back to the last merge point on the branch. If you don't you will increase the number of conflicts that you will have. eg: ----mp(1)----mp(2)--- when merging mp(2) do: cvs up -j mp-1 -j mp-2 * instead of: cvs up -j mp-base -j mp-2 * I hope this helps, -- Tom. ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
