Subversion hosting, CVS hosting, Bugzilla hosting and software collaboration Providing hosted Subversion, CVS and Bugzilla repositories

Ask The Source

Go To My Account
Bugbox Icon


This month's question - Winter 2006

Q: Hi Greg,

We're using your CVS hosting solution, and we need
to release incremental bug fixes to our software while
also working full-steam on our next release. How can
we do parallel development with CVS?

A: You can easily accomplish this with "branching" and "merging" in your CVS repository.

Branching is an operation that creates separate instances of your source code files so you can work on them in parallel. Once you finish working on a branched version of a file, you merge it back into the master version of the file to incorporate its changes.

For the sake of argument, let's assume that your released software version is 1.0, and you are working toward your next release of version 1.1.

In the meantime, a customer has found a critical bug in version 1.0 that must be fixed and released before version 1.1 is ready to ship. In order to release an update, you only want to make a change relative to version 1.0 without releasing any of the untested code that is slated to become version 1.1.

To do this, you should already be in the habit of tagging your major releases that are packaged and delivered to customers. That is done with the "cvs rtag" command like so:

cvs rtag REL_1_0 KillerApp

That command applies the tag "REL_1_0" to all committed files in the "KillerApp" module in your repository, and that's an easy way to identify them if or when a bug fix branch must be created. In fact, many development teams immediately create a bug fix branch when version 1.0 is released, like so:

cvs rtag -b -r REL_1_0 REL_1_0_bugfix KillerApp

"REL_1_0_bugfix" is the branch tag that indicates where all bug fixes for version 1.0 will be committed.

Now, when a bug fix is made for version 1.0 of your application, first switch to the bug fix branch, then make the change and commit it:

cvs update -r REL_1_0_bugfix KillerApp

<<edit source files, fix bugs, test the fixes>>

cvs commit KillerApp

You can even (and should!) tag your incremental bug-fix releases when they are released to customers, like so:

cvs rtag REL_1_0_1 KillerApp

You can then switch back to the ongoing version 1.1 development on the main trunk with the following command:

cvs update -A KillerApp

Finally, when version 1.1 is feature-frozen or earlier, you merge the bug fixes committed to the REL_1_0_bugfix branch into your main line of development. That way, version 1.1 contains the new features and the bug fixes from version 1.0. The merge command is "cvs update" with the special "-j" argument:

cvs update -j REL_1_0_bugfix KillerApp

After the merge command, you may have to resolve some file conflicts manually. Conflicts are locations in your source files where changes were made both in the main line of development and on the branch. You can find more information about conflicts and how to resolve them here.

Once all conflicts have been resolved, commit the merged files like so:

cvs commit KillerApp

Congratulations, you are now ready to test and release version 1.1 of your application, and it includes all of the bug fixes from version 1.0!

Ask the Source is a regular feature of the email newsletter,

Do you have a question for The Source? Submit one today, and we'll review it for inclusion in a future edition of!

For a complete list of all "Ask The Source" questions and answers, please visit the archives page.



News (more...)

Articles (more...)

Sign up for or view archives




hosted solutions | pro servs | company | sales | support | resources
home | contact | client login

Copyright © 1999-2017, LLC. All Rights Reserved.
usage agreement | policies