I believe that it is often a good idea to have another set of eyes looking at the code I write. The questions and comments resulting from such a code review indicate its value:

  • “It seems like you are missing a test case for this scenario, and I think the code will break on it”
  • “We already have some code elsewhere that implements this functionality; please reuse that”
  • “That was a nice way to implement this function. I can use that elsewhere”
  • “Now I learned about this new feature of CSS”

Code reviews can be done in many ways. Some prefer pair programming: review the code as it is being written, while others prefer to work alone writing the code and then having someone review it afterwards. Some companies have a policy mandating code reviews before the code is comitted, while others others prefer to increase the flow by allowing code reviews after commit. A discussion of the pros and cons of these different approaches in different situations is worth a seperate post.

Lately I have wanted to do code reviews after commits on one of our projects. To make it as easy as possible to manage the code reviews, I have looked for a tool that allowed me to easily mark commits with the name of a reviewer, and easily get a list of commits not yet marked as reviewed. GitHub has built-in support for code reviews of pull requests. However I needed a solution that worked with our SVN repository. Several dedicated code review tools exist, but I was discouraged by the complexity added by those tools.

Then I found a simple solution utilizing a feature in TortoiseSVN that was made for integration with issue trackers. Now I can use the Log window in TortoiseSVN to see which commits have been reviewed by whom. Here is a sample screenshot:

I can search for commits that have not yet been reviewed:

If the code was written by a pair, the name of your partner can be written directly in the commit dialog, see this sample screenshot:

If the code is reviewed some time after the commit, the commit can be marked as reviewed by adding the review information in the Edit Log Message dialog:

To configure TortoiseSVN to behave in this way, all you have to do is to commit the following revision properties on the root folder of your project:

Thanks to the TortoiseSVN team for making such a great versatile product!

9 comments on “Lightweight code reviews using TortoiseSVN

  • Note that you have to disable the log cache to make this work. Otherwise the log dialog shows the cached entries and you won’t see the edited messages if the message hasn’t been edited on your own machine.

  • You didn’t really explain how to add the reviewer property to the list of fields in SVN. On the latest SVN, there doesn’t seem to be an easy way to do this. Would you write out some better step by step on how to add the property?

    • Hi,

      Thanks a lot for this post, very useful.
      I can’t find a way to add the Reviewer property to the list of fields in SVN “Log Messages” view either and would be grateful if you explained us how to do it.


      • Refer to the final screen shot above. To “commit the following revision properties on the root folder of your project”, what you need to do is: 1) right click the root folder in Windows Explorer and choose “Properties”. On the “Subversion” tab, click “Properties”. This gives you window in the screen shot. There you can click “New…”, select “Bugtraq”. This will show the “Edit bugtraq properties” window. Here you can enter “Message pattern:” = “Reviewer: %BUGID%”, “Message label:” = “Reviewer” and select “Arbitrary text” for “Bug-ID is:”. That should do it!

        • On my Tortoise, it seems you should not leave the bugtraq:url field empty to have the field “Reviewer” in the “Log Messages” window.

  • HI, I am using TSVN version 1.7. Yhough during checkin it is asking for reviewer name , I cannot see these feilds in the log window

  • I am using TSVN 1.7.10. Do you have the bugtraq:label property comitted to the SVN properties of the root folder, as shown in the final screen shot? See also my comment above. If you still cannot get it to work, email me (http://www.zealake.com/contact/) some screenshots of your setup.

  • It seems that what you’re doing here is overriding the BUGID feature. By using BUGID as REVIEWER, you’ve lost the ability to have the actual BUGID used, e.g. as a link to the issue in the bugtracker. Maybe useful for you, but FAIL for anyone who is actually using a bugtracker and wants Tortoise to link to it.

Leave a Reply

Your email address will not be published. Required fields are marked *