«« Having Stable and Development Branches AudioMan 0.2.0 Released »»
blog header image
CVS Branching

Here's a summary of my understanding of CVS branching. If anything is wrong please let me know. Note the difference between the words revision and release.

CVS has a notion of a main development trunk (tree analogy) also called HEAD. You may branch off from the trunk and check in changes only to the branch without affecting the trunk. You may also merge the branch back to the trunk one or many times.

All of the new AudioMan development will happen on the trunk. I'll branch off 0.2 so that I can make maintenance fixes. Then I'll tag releases 0.2.1, 0.2.2, etc on that branch. Concurrently I'll also be tagging releases 0.3.1, 0.3.2, etc on the trunk.

For each source code file, CVS stores all of the revision information for the trunk and the branches in the same place. It can tell changes from the trunk apart from changes to branches by using a hierarchial system of revision numbers.

For each file tags are kept as well. Tagging a file is a good way to mark a specific product release even though individually all of the source files probably have different revision numbers at the time you tagged them.

When you create a branch it's important to realise it's being done in the repository on each file. Branches always have a root, which is a tag on the trunk marking where the branch came from on the trunk. It is used to merge changes back later.

For example I could tag AudioMan version 0.2.0 on the trunk and then branch off from it, continuing 0.2 development from that point on the branch. The trunk would then be used for 0.3. When I wanted to merge a minor bugfix I made in the 0.2 back to the trunk, it would use the root tag as a comparison point to figure out the difference between the branch, the file at the time of the root tag and the present trunk.

Incidentally it looks like I'll tag 0.2.0 when it is ready and then wait until the first development release to tag 0.3.0. Sometimes the first development release is x.y.1 instead but it doesn't really matter. For example there didn't seem to be a 2.5.0 release of the Linux kernel but there was a 2.3.0 release.

For stable releases Bugzilla has 2.16 instead of 2.16.0. I think it's a bit confusing not having the last digit because 2.16 could refer to the series of releases rather than a specific version.

I'm setting up the AudioMan CVS server for this and the module AudioMan might be in flux for a bit. I'll post an update when it is ready. Until then use module AudioManPoint2.

Update 9:09 AM: OK, module AudioMan is ready now. Rather than synchronize with this new version of the module, you are better off deleting what you have and checking AudioMan out again.

Posted at February 24, 2004 at 03:14 AM EST
Last updated February 24, 2004 at 03:14 AM EST
Comments

You might want to check out Subversion. I've been using it a on my latest school projects. Seems to be working pretty good. It's basically the tool that's supposed to replace CVS. It's supposed to have this whole branching thing fixed. Basically, it's as easy as copying the current version, to some other folder, and treating the new copy like a seperate branch. Makes a lot of sense to me.

» Posted by: Kibbee at February 25, 2004 01:23 AM

I planned on checking out (no pun intended) Subversion but I was waiting for the verdict from Roy.

I don't know how much I can trust the Subversion Eclipse plugin. Has anyone used it?

At any rate I'm glad I learned about CVS. Companies are still using it all over the place.

» Posted by: Ryan at February 25, 2004 06:31 AM
Google
 
Search scope: Web ryanlowe.ca