|
 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 SourceHosting.net
email newsletter, SourceHosting.news.
Do you have
a question
for The Source? Submit
one today, and we'll
review it for inclusion in a future edition of SourceHosting.news!
For a complete list of all "Ask The Source"
questions and answers, please visit the archives
page.
|
