I’ve already told you about releasing your project with help from Subversion. Now I want to talk to you about using Subversion to fix bugs in your application.
Fixing bugs can be as easy as fixing a few lines of code or as hard as rewriting a significant portion of your application. Both situations need a different approach from us. Let’s talk about the easy stuff first.
For this example let’s say we have a project. It has a release branch named RB-1.0 and current development is going on in the trunk.
A user has submitted a bug report (numbered #3391) against your 1.0 release. Here’s what to do:
Easy bug fixes#
Let’s say bug #3391 is an easy fix. First, check out a working copy of the release branch.
svn co https://example.com/branches/RB-1.0 rb-1.0
Now, go in there, write tests that expose the bug and fix it. As I said, it’s an easy fix so you can commit all your changes at once to the release branch. When you do this, remember the new revision number.
Note: it’s always smart to include the number of the bug (in this case #3391) in your commit message. This will make sure other developers (and later on, yourself) know what bug was fixed here.
$ svn commit -m "Bug fixed #3391"
...
Committed revision 183.
As I said, remember the revision number: 183.
Now you have the bug fixed in the release branch for version 1.0, you are probably wondering if the bug exists in your current development code as well. Since branches are plain copies of your development code, the big probably is there too.
Don’t start editing your working copy of the trunk and start fixing the bug all over again. Let Subversion do the work.
Go into your trunk working copy and update it to the latest revision, this is revision 183. But, we only made changes to the release branch, and not to the trunk, so we need to merge those changes. We can do this by running the following command:
svn merge -r182:183 https://example.com/branches/RB-1.0 rb-1.0
You’ll now see the fix you applied in the release branch getting merged with your current development code. Great, isn’t it?
Before you leave to party, don’t forget to commit the changes to the trunk. Again, name the bug number you fixed here and also which revision you userd to merge it.
svn commit -m "Merge r183 (bug fixed #3391)"
You can apply this merge process with any other release branch you have if that’ necessary.
Difficult bug fixes#
Another scenario is that the bug is not easy to fix. You need to rewrite a lot of tests to expose the bug in the first place, and even then you’re not sure how to go about fixing it.
If that’s the case, you are better of creating a seperate bug fix branch. This allows you to fix the bug in the background, possibly with the help of others, while current development can still go on. Also, you want to create snapshots of before (pre) and after (post) the bug fix. These tags will help you merge the fix into other branches later on.
First, create a bug fix branc. By convention Release Branches were called RB-1.0, Bug fix branches are called BUG-###. Of course, ### corresponds to the bug report number. In this case we create a branch named BUG-3391. We also need to create a snapshot of the code before we start fixing the bug. We call this tag PRE-3391.
svn copy -m "Create bugfix branch" https://example.com/branches/RB-1.0 https://example.com/branches/BUG-3391
svn copy -m "Tag start of bug fix" https://example.com/branches/BUG-3391 https://example.com/tags/PRE-3391
Now, you can checkout the bug fix branch and start work. You may call in the help of others if you need to. It’s okay to make multiple commits to this branch.
When you have reached the point were the bug is fixed, you’ll need to mark the end of it. We create a new tag named POST-3391 to mark the end of the bugfix:
svn copy -m "Tag end of bug fix" https://example.com/branches/BUG-3391 https://example.com/tags/POST-3391
Well. You’re done! Your bug has been fixed! But wait a minute. The fix is not present in the release branch yet! Here, again, we need to merge the bug fix into the release branch (and possibly into the trunk also).
First, update your current working of the release branch and merge the changes between the PRE-3391 and POST-3391 tags with the release branch. When done, run your tests to make sure everything works as expected and commit your changes.
svn update
svn merge https://example.com/tags/PRE-3391 https://example.com/tags/POST-3391
svn commit -m "Merged bug fix for bug #3391"
Final note#
It’s clear that fixing bugs the easy way is the preferred method. Try to use this method as much as possible. But it’s okay to use the difficult way to solve the more difficult bugs.
Putting the bug report number into Subversion comments is a good way to keep track of what code changes have been made based on what bug report. Most bug tracking tools can make use of this and link bug reports to the appropriate revisitons and visa-versa. If your bug tracking tool doesn’t have this ability, it’s a good idea to comment the appropriate revision number or tags on the bug so that others know where to look for the fix.
Happy bug fixing!