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.
Contributions show up on the review list
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.
Use the controls on the merge request to write comments (you can @mention the contributor), vote, and view changed files and diffs.
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.