How to make sure bug fixes in a version branch in Subversion are merged into the trunk

Question

We are managing our software versions as branches in Subversion. The latest upcoming release is the trunk. Older released versions are a branch (also tagged per build and release). When a developer is fixing a bug in an older version, it is his responsibility to merge the fix into the trunk. In case this step is missed, it is hard to notice until, maybe, the bug shows up again in a later version. Then we have to debug and fix it all over again.

Is there a way to monitor the merges to make sure they are done?

Or is there a better way to use Subversion's branching to get better results.

UPDATE: People pointed the solution should include a bug tracking system. We do use Jira and mark every commit with the Jira issue ID. No further integration is implemented right now.

It is possible the solution is in having a better process. But if there are any tools to support this better process, I would like to learn about their existence, or the way to use them.

Answer 1

Beginning with version 1.5, SVN puts information about merged revisions into the properties. You should be able to find it there and make sense of it. However, this only tells you which revisions were merged, not which revisions were forgotten to merge.

In the end, I guess, it all boils down to those who make a fix on a branch also being responsible for merging it into the trunk. The best way to make sure that happens probably is peer pressure. :)

Answer 2

Newer versions of subversion (I think, starting from 1.5 or 1.6) have a merge tracking. That is, the subversion keeps track which of the changes in branch have been merged to trunk.

You can merge all changes from the branch to the trunk using command:

svn co https://server/repo/trunk
cd trunk
svn merge --reintegrate https://server/repo/branches/branch_name
<check merge results, run unit tests, etc>
svn commit

See Subversion manual for more details.

This way you'll get all the changes done in branch to arrive to trunk. However if you do not want to get all changes from branch to trunk you must use svn diff to notice changes and select changes you want to merge.

Answer 3

First, the way to be sure these things get done is to record the checkin of the fix on the version branch and the checkin of the merge to the trunk in the bug's entry in your bug tracking system. If you don't have a bug tracking system, get one. Besides helping with tracking fixes, it solves many other issues with tracking the status of bugs.

Second, you may want to consider an alternate approach. When you duplicate a bug in a released version, try and duplicate it in the head of the trunk too. Most of the time you'll find it is still occuring. Fix it in the trunk and check that fix in. Then merge the change back into the branches for already released versions that need the fix (you may have to modify the fix to account for the different environment). If the bug only occurs in a release branch, then it fix it there (it doesn't need to be merged to the trunk).

Answer 4

If your bugs are in a bug tracker (and they should be), you can use it to track this. There should be some way in your bug tracker to mark which versions are affected.

To make sure that a closed bug is actually resolved, QA/testing people should test that the bug is actually fixed in all supported releases.

SVN's merge tracking can help some, but ultimately it can't tell you:

• was the bug fixed by an unrelated change on trunk, and this no patch was needed?
• did the patch from branch not work on trunk, due to other changes?
• did the patch from branch not apply at all to trunk, and a different patch was needed on trunk?

Testing is really the best way to be sure a bug is gone. If you don't have QA/test people, you can have a different developer do it or hire software testers.

Answer 5

There's nothing in SVN to tell you what code you should or should not checkin, branch, merge or delete. That's not its job. It does its job perfectly well - which is providing you with a versioned tool to store your code in.

So, you don't need a tool to manage your code better, you need an external system to manage your developers better :)

One way is QA, test and a bug tracker - as code changes are made, the fact that something was done to the code is recorded and tracked through the various phases. You typically do not want anyone making changes to code without some reason (other than 'I felt it needed refactoring') so a tracking tool is a good idea anyway. As bugs are fixed in one release, this tool can be used to ensure that the bug is fixed in other ones too (when appropriate - sometimes you don't want a particular change made to a release)

SVN can integrate with these tools, for example, my repo updates my Mantis bugtracker when some magic words are added to a checkin (if you type "fixed mantis #1234" in the checkin comment, mantis bug 1234 will be updated with the changed files and its status changed to 'waiting test')

Alternatively tools such as reviewboard can integrate too - as you make a change, the revision can be posted there for others to sign off, sign off process can include ensuring the bug is merged, or a new bug report is created for the other releases you require it fixing in too.

So - the problem is not with SVN here, its with your development processes.

Answer 6

You might want to adapt the strategy Subversion developers use themselves: do most of the development in trunk, release from branches. When a bug is found it's first fixed in trunk and then the fix is merged from trunk to the branch.

Answer 7

Here is what we're doing, I just blogged about it - we setup a special build in our CI server that makes sure, on a nightly basis, that no unmerged changes exist.

Answer 8

Hi there,

I actually wrote a script a little while back to do exactly that. We had a number of simultaneous branches going on a project I was working on, and it was very difficult to keep track of all commits and merges.

You can find the script at: http://github.com/ccampbell/show-missing-revs

Let's say you have a 2.0 release branch. To find out everything committed in 2.0 that has not yet been merged to trunk:

cd /path/to/trunk
sh /path/to/show_missing_revs.sh -b 2.0 -u username (optional) -v (verbose)

This will output something like:

r2532 | username | fixing bug with this
r2631 | username | fixing bug with that

This requires subversion 1.5 I believe. Hope you find this useful!