How to audit your Subversion branches
One of the greatest features of Subversion (and any other decent source control tool) is the ability to branch. Branching allows development to occur in parallel streams and allows changes to be safely propagated from one development stream to another.
These features work well, but one often finds that developers forget to merge their changes back to the main development stream, or to use Subversion's terminology, developers forget to "merge back into the trunk."
Now there are several steps that one can take to ensure that this does not happen. One method is to insist that developers merge their changes back into the trunk immediately, but under high pressure forgetfulness is rife.
This is where the daily audit fits in. For a daily audit, you simply generate a log of yesterday's branch commits and try to match them to yesterday's trunk commits.
Using Subversion, here is the process step by step:
Step 1: Get a log of yesterday's branch commits
I prefer using the command line to do this. That way I can send the log to a text file. To get the branch commits for yesterday (5 June 2007), I use the following command line:
svn log https://localhost/svn/projects/Foo/branches/2.x -r {2007-06-05}:{2007-06-06} > c:\branches.txt Let's say that the file branches.txt looks like this:
------------------------------------------------------------------------
r205 | tom | 2007-06-04 18:32:47 +0200 (Mon, 04 Jun 2007) | 1 line
Added view persistence for ChooseCountry View
------------------------------------------------------------------------
r207 | mick | 2007-06-05 14:59:57 +0200 (Tue, 05 Jun 2007) | 1 line
Added SharpZipLib.dll to implementation/lib/
------------------------------------------------------------------------
r208 | harry | 2007-06-05 15:27:13 +0200 (Tue, 05 Jun 2007) | 1 line
The report was displaying generalName in the place of comradeName. Corrected the error.
------------------------------------------------------------------------ In this file we have 3 revisions. We can ignore the first entry as it falls outside the date range that we specified.
Step 2: Get a log of yesterday's trunk commits
Execute the svn log command again:
svn log https://localhost/svn/projects/Foo/trunk -r {2007-06-05}:{2007-06-06} > c:\trunk.txt Now assume that the trunk.txt file looks something like this:
------------------------------------------------------------------------
r206 | tom | 2007-06-04 18:35:40 +0200 (Mon, 04 Jun 2007) | 1 line
Merged revision 205 from the 2.x branch
------------------------------------------------------------------------
r209 | harry | 2007-06-05 15:30:31 +0200 (Tue, 05 Jun 2007) | 1 line
Merged revision 208 from the 2.x branch
------------------------------------------------------------------------ Again we can ignore the first entry because it comes from 2 days ago. At this stage I print the two files out.
Step 3: Mark off the branch commits that have been merged
Notice two things about the log messages in the trunk's log: First, it contains the word merged. This makes the log searchable. Having a searchable log will make the audit process a lot easier as it allows you to grep the relevant log messages.
Second, notice that the revision number of the branch commit and the branch instance is included. This allows you to trace the exact log entry in the branch's log. When you have located the log entry on the branch's log, mark it off.
From this example, you will notice that the user mick has not merged his changes from revision 207 to the trunk.
Step 4: Follow up
If "missing" merges are detected, it is probably a good idea to find out why. Perhaps forgetfulness has crept in. Perhaps that revision was not intended to be merged to the trunk.
I hope that this is useful. It has served me very well over the past six months or so as I review the work of my fellow developers. I hope that it will serve you too.