Wednesday, March 19, 2008

Code Reviews using Subversion

I am a big fan of code reviews.  Code reviews are important for ensuring good design principles and to make sure that BAC (buggy ass code) doesn't make its way into your application.  I have recently adopted a model that I am sure the open source community is familiar with, which is using Subversion patches as a means by which to conduct code reviews.  The process is divided into a few component tasks.  One of the biggest parts of this process is the developer that is making the code change, major system enchancement or whatever will create their own feature branch in subversion.  If you are not sure how to create a branch the TortiseSVN guide, or the Subversion guide (if you are a command line junkie) are informative on this subject.


So lets step through a simple example.  Lets say I need to cut a feature branch off of the trunk.  I have a local working copy of the trunk in a directory c:\trunk.  I then use my tool of choice to create a branch call NewFeatureBranch from this working copy (You are actually creating a branch from the subversion trunk).   Then you create a directory structure of your liking on your local machine to check this new branch into.  What I typically do is create a directory hierarchy that represents the release you are working toward, so for example if I am working on a feature in the 3.1 release of my product I will have a directory named c:\ProductName_V3x0x1\NewFeatureBranch.


The c:\ProductNameV3x0x1\NewFeatureBranch is the working copy you will make all of your changes in.  Feel free to check in, roll-back, add new libraries in this working copy, or whaever you need to implement the feature.  When you are ready for code review it is time to do two things.  First update your working copy of the trunk so that it is completely green.  In other words there are no differences between the working copy of the trunk and the subversion repository.  Next merge from your branch to your working copy of the trunk (or the branch you cut from).  When you perform this function you may have conflicts and you will definately have changes.  Address all of the conflicts accordingly and then use subversion to create a patch from the root of your project.  A patch in subversion terms is simply a collection of all of the diffs of your code.  If you follow this process the patch will only contain your diffs and this patch can be circulated for code reviews.


The person who receives your patch will always perform an update on the trunk (or whereever you cut your branch from) before performing the review.  Once the update is complete the code reviewer will by convention apply the patch to the root of the project unless you tell them otherwise.  This will enable the reviewer to see the diffs of your code, make comments in your code and submit a patch to you with either code changes, comments etc.  This process has worked very well for me in the past, and I continue to use it today.


Powered by Qumana

No comments: