Comments on: Pre-Commit Code Review in MarkUs Development http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/ The personal blog of a Toronto based software developer, musician, sound designer, and theatre enthusiast. Tue, 24 Jan 2012 15:00:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Jesse Gibbs http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/comment-page-1/#comment-824 Jesse Gibbs Tue, 09 Feb 2010 02:32:25 +0000 http://mikeconley.ca/blog/?p=977#comment-824 This is a very interesting post. I think that DVCS such as Git and Mercurial could address a few of the issues highlighted here, namely: Check in early, check in often: With a DVCS, you can check-in to your personal or a topic branch, but you don't necessarily have to merge the changes into your main trunk (the 'one source of truth' from which you actually release software). If developers are able to initiate and perform code reviews from personal/topic branches, then they can avoid 'polluting' the trunk with unreviewed code, and also be confident that their changes will not be lost due to an errant edit on their local copy. Lack of working code: Intelligent use of DVCS should allow the reviewer to look at an actual working copy of the code under review, since they can access the changes in other personal/topic branches, and are not strictly limited to pulling code from the trunk. I suspect that if usage of DVCS becomes really widespread, we might see 'pre-commit reviews' and 'pre-commit builds' replaced by DVCS-enabled processes that involve multiple stages of build, test and code review before a change is merged into the primary trunk from which releases are created. An example workflow could be: Make a change --> Commit to personal/topic branch --> Compile/test based on branch --> Peer code review on personal/topic branch --> Commit to trunk for release The number of steps between committing a change to a personal/topic branch and inclusion of that change into the 'trunk' is arbitrary, and allows teams to be as rigorous as they want about maintaining the tidiness of trunk without preventing changes from being committed into some form of version control. Thoughts? This is a very interesting post. I think that DVCS such as Git and Mercurial could address a few of the issues highlighted here, namely:

Check in early, check in often: With a DVCS, you can check-in to your personal or a topic branch, but you don’t necessarily have to merge the changes into your main trunk (the ‘one source of truth’ from which you actually release software). If developers are able to initiate and perform code reviews from personal/topic branches, then they can avoid ‘polluting’ the trunk with unreviewed code, and also be confident that their changes will not be lost due to an errant edit on their local copy.

Lack of working code: Intelligent use of DVCS should allow the reviewer to look at an actual working copy of the code under review, since they can access the changes in other personal/topic branches, and are not strictly limited to pulling code from the trunk.

I suspect that if usage of DVCS becomes really widespread, we might see ‘pre-commit reviews’ and ‘pre-commit builds’ replaced by DVCS-enabled processes that involve multiple stages of build, test and code review before a change is merged into the primary trunk from which releases are created. An example workflow could be:

Make a change –> Commit to personal/topic branch –> Compile/test based on branch –> Peer code review on personal/topic branch –> Commit to trunk for release

The number of steps between committing a change to a personal/topic branch and inclusion of that change into the ‘trunk’ is arbitrary, and allows teams to be as rigorous as they want about maintaining the tidiness of trunk without preventing changes from being committed into some form of version control.

Thoughts?

]]> By: Feb. 5th Status Update at MarkUs Blog http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/comment-page-1/#comment-777 Feb. 5th Status Update at MarkUs Blog Fri, 05 Feb 2010 05:53:45 +0000 http://mikeconley.ca/blog/?p=977#comment-777 [...] a handy-dandy script that lets me test drive diffs-for-review quickly and easily. See http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/ towards the bottom. I’m going to polish this tool up and upload it somewhere if people are [...] [...] a handy-dandy script that lets me test drive diffs-for-review quickly and easily. See http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/ towards the bottom. I’m going to polish this tool up and upload it somewhere if people are [...]

]]> By: Joe Wright http://mikeconley.ca/blog/2010/02/02/pre-commit-code-review-in-markus-development/comment-page-1/#comment-766 Joe Wright Wed, 03 Feb 2010 15:03:58 +0000 http://mikeconley.ca/blog/?p=977#comment-766 Hi Mike, This sounds like a good feedback loop you've introduced to your environment. I'm glad to hear of it's successful adoption. We get around the checking broken code into the repo problem by using "pre-tested commits" in TeamCity: http://www.jetbrains.com/teamcity/delayed_commit.html I'm seeing some parallels with testing branches and the approach you've taken, developers can cheaply branch the mainline and put their experimental code into SCM for review. Especially with distributed SCM where we are all encouraged to branch liberally. Hi Mike,

This sounds like a good feedback loop you’ve introduced to your environment. I’m glad to hear of it’s successful adoption.

We get around the checking broken code into the repo problem by using “pre-tested commits” in TeamCity:
http://www.jetbrains.com/teamcity/delayed_commit.html

I’m seeing some parallels with testing branches and the approach you’ve taken, developers can cheaply branch the mainline and put their experimental code into SCM for review. Especially with distributed SCM where we are all encouraged to branch liberally.

]]>