zhao-sun.com

• as root, create the source direcory, and run “cvs init”. This will create CVSROOT directory.

• set the correct value to CVSROOT inside your login batch
  file, such as in my .cshrc, I say “setenv CVSROOT /src/master”.

• for importing into the source repository, first go the directory with the sources, and run “cvs import test yoyo start”.

• for checking out, after set correct CVSROOT, do “cvs update -d” or “cvs co [source module name]”.

• for create a personal branch, do “cvs rtag -b [branch name] [souecr module name]”, and then run “cvs update -r [branch name]”.

  Or you can go to cvs document page to take a look.
  

Tag and Create a new branch

When your mainline is ready to ship, tag it. You have to do this anyway to remember what you shipped.
• cd an_up_to_date_working_copy
  
• cvs tag main_1_0

  Create a branch and put the working copy on it.

• cvs tag -r main_1_0 -b B_1_0_branch
  
• cvs update -r B_1_0_branch

  Make the changes for customer B, and commit them as you go. Because your working copy has a sticky tag from the “update -r B_1_0_branch”, your commits go to that branch instead of the trunk.

  When your branch is good, tag it too.

• cvs tag B_1_0

  You can now go to a clean directory and export revisions main_1_0 and B_1_0 for shipping.

  Return to your working copy and put it back on the trunk.

• cvs update -A

  All your “B” changes are gone, you are back to the mainline. Proceed with normal development. When your mainline is ready to ship again, tag it.

• cvs tag main_1_1

  Now the fun part: you create a new branch for customer B and recreate all the changes you made the first time.

• cvs tag -r main_1_1 -b B_1_1_branch
  
• cvs update -r B_1_1_branch
  
• cvs update -j main_1_0 -j B_1_0
  
• # fix conflicts
  
• cvs commit

  The “update -j -j” does most of the work for you, but it’s not foolproof so you have to manually inspect and test your sources. You’ll be surprised how little damage you have to fix. When you’re happy, tag the tip of your new B branch.

• cvs tag B_1_1
  
• cvs update -A

  The process repeats after the second release. Tag, create new branch, merge the previous branch to it. You have to be very clear about the use of those branches: all development happens on the trunk, the “B” branches are *only* for customer-specific variants. You never merge these branches back to the trunk.

  (In truth, you should also have bugfix branches for the normal code you ship, but that’s an easier pattern to master than the stepladder of branches I just described. Stick to the hard stuff for now… 🙂