Try the new Subversion code review and merge requests

Posted by Andy Singleton on December 13, 2012 14:55:00 PM

Your Source/SVN tool now supports a modern code review and code contribution process. You can see it under the new "Review code" subtab.  It is similar to the workflows enjoyed by git users to include a large number of contributors or to review code for continuous integration and continuous delivery.  You can put your changes in a branch, review them, and merge them through a Web-based UI.

This first release has a simple workflow that requires users to manage their own branches.  Please leave a comment with your feedback.  After we are sure that this is working smoothly, we will enhance it with much-requested features like extra permissions on trunk (to push contributions into reviewed branches), one-button branch creation, and inline code commenting.

How it Works:

Make a temporary branch.  Write your changes and commit them.

Make a merge request.  You only need to select the source branch. We already know how to merge it to the destination it was branched from.

create merge requests resized 600

Contributions show up on the review list

mr list resized 600

Select a merge request to review.  You can open the "Get Changes" link to see instructions for merging and testing the changes.  In most cases, you want to test the result of merging the change with trunk (or the source that you branched from).  So, the instructions will ask you to switch to trunk, and merge the changes.

merge instructions resized 600

Use the controls on the merge request to write comments (you can @mention the contributor), vote, and view changed files and diffs.

view diff resized 600

Subversion merge requests have a lot of the same great features that are in our git merge requests.  For example, they get linked to tickets when you include a #ticket link in your commits.  So, when you can see the status of the relevant code changes.  And, when you look at a merge request, you can see the tickets you are working on.

Patch or branch?

A lot of Subversion code review systems use patches.  You make a patch (a diff file with the changes) and you upload it to a code review system like Reviewboard, or you email it to a list of reviewers (Subversion developers do this on the Apache Subversion developers list).  The advantage of a patch is that it is easy for a reviewer to apply it to whatever version of code he is working on, and it doesn't need to be integrated with your repository server.  However, it is annoying to make and upload a patch, and you can't fix it.  If you see a problem in a branch, you just switch to the branch and fix it.  We discussed this with our own team, and with some of the Apache Subversion core developers, and we decided that we prefer reviewing and sharing real branches.

We hope that you see some benefit in the branch-based workflow.  Get it for free with Assembla Renzoku.

Get The World’s Best Subversion Hosting Here!

Get started today with a 14–day FREE trial.

No obligations, no credit card required.

Get Started Now

About the author

Andy SingletonWorking on Continuous Agile and Accelerating Innovation, Assembla CEO and startup founder

Get updates about development, productivity, and teamwork