How to verify that bug fixes in a version branch in Subversion are merged into a trunk

Question

We manage our software versions as branches in Subversion. The latest upcoming release is the trunk. Older released versions are a branch (also marked for assembly and release). When a developer corrects a bug in an older version, he is responsible for combining the bug in the trunk. If this step is skipped, it is difficult to notice it until, possibly, the error appears again in a later version. Then we have to debug and fix it again and again.

Is there a way to control mergers to make sure they are completed?

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

UPDATE: People have indicated that the solution should include a bug tracking system. We use Jira and mark each commit with a Jira problem identifier. No further integration is currently in progress.

Perhaps the solution has a better process. But if there are any tools to support this better process, I would like to know about their existence or how to use them.

Answer 1

If your errors are in the error tracker (and they should be), you can use it to track this. There must be some way in your bug tracker to note which versions are affected.

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

Tracking SVN mergers may help some, but ultimately it cannot tell you:

• was there a mistake corrected by an unrelated change on the outside line, and it was not fixed?
• The patch from the branch did not work on the torso due to other changes?
• A patch from a branch is not applicable to the trunk at all, and another patch was needed on the trunk?

Testing is really the best way to make sure that the error has disappeared. If you do not have QA / test users, you can use another developer or hire software testers.

Answer 2

Starting with version 1.5, SVN places merged revision information into properties. You have to find him there and understand. However, this only indicates which revisions were merged, and not which versions were forgotten to merge.

In the end, I think it all comes down to those who make the correction on the branch, also responsible for merging it with the trunk. The best way to make sure that this is possible is peer pressure. :)

Answer 3

You might want to adapt the strategy. Subversion developers use themselves: do most of the development in the trunk, get rid of branches. When an error is detected, it is first committed to the trunk, and then the patch is combined with the trunk to the branch.

Answer 4

There is nothing in SVN to tell you which code you should or shouldn't check, fork, merge, or delete. This is not his job. It does a great job - it provides you with a means for the version to save your code.

So, you do not need a tool to better manage your code, you need an external system to better manage your developers :)

One of the ways - quality control, testing and tracking errors - when changing the code, the fact that something was done with the code is recorded and monitored at different stages. Usually you don’t want anyone to make changes to the code for no reason (other than “I felt like I needed refactoring”), so a tracking tool is a good idea. Since errors are fixed in one release, this tool can be used to ensure that the error is fixed in others (if necessary - sometimes you do not want any change to be made to the release)

SVN can integrate with these tools, for example, my repo updates my Mugis bugtracker when some magic words are added to checkin (if you enter “fixed mantis # 1234” in the verification comment, mantis error 1234 will be updated using the modified files and its status changed to "wait test")

Alternatively, tools, such as a dashboard, can also be integrated - when you make changes, the revision can be placed where others can subscribe, the registration process may include providing a consolidation of the error or creating a new error report for other releases in which you also in need of correction.

So, the problem is not SVN, but its development processes.

Answer 5

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

You can merge all changes from the branch to the trunk using the 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 the Subversion Guide for more information.

This way you will get all the changes made in the branch to get to the trunk. However, if you do not want to receive all changes from the branch to the trunk, you must use svn diff to notice the changes and select the changes you want to merge.

Answer 6

First of all, the way to make sure that all this is done is to record the patch check on the version branch and the boot merge check in the bug record in your bug tracking system. If you don’t have a bug tracking system, get one. In addition to assisting with tracking fixes, it solves many other issues with tracking error status.

Secondly, you can consider an alternative approach. When you duplicate a bug in the released version, try and duplicate it in the head of the torso too. In most cases, you will find that this is still happening. Fix it in the trunk and check that fix. Then merge the changes back into branches for already released versions that need to be fixed (you may need to change the fix for the account for another environment). If the error occurs only in the release branches, then it corrects it there (it does not need to be combined with the trunk).

Answer 7

Here's what we do, I just talked about it - we set up a special build on our CI server, on a nightly basis, so that there are no unrelated changes.

Answer 8

I actually wrote a script a while ago to do just that. We had several simultaneous branches that worked on the project that I was working on, and it was very difficult to track all the commits and merges.

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

Say you have release 2.0. To find out everything that was done in version 2.0, not yet integrated with the trunk:

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

This will result in:

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

This requires a subversion of 1.5. Hope you find this helpful!