views:

2537

answers:

3

At my company we are trying to add code reviewing practices into our development process and for that purpose we decided to use Review Board.

While Review Board should work out of the box for Subversion the workflow for Mercurial looks a little bit involved. Firstly it seems that only post reviewing(via post-review script) is supported for this type of repo. Secondly documentation is unclear whether post-review actually supports Mercurial(it only mentions git).

Could you folks describe your workflow in detail please?

Am I right in my thinking it should be something like this:

Developer:

  1. clone master repo
  2. clone feature repo from local master repo
  3. hack-hack in feature repo
  4. commit into feature repo
  5. somehow run post-review from feature repo against parent master repo

Reviewer:

  1. review diff
  2. if OK then pull to the master repo from the feature repo
+2  A: 

There is an extension for mercurial for what you want to do:

http://blogma.de/projects/mercurial-reviewboard.html
http://www.selenic.com/mercurial/wiki/ReviewboardExtension

The work-flow you present seems easy to follow so I think that you are on the right track. The way the DVCS services (i.e. bitbucket or github) handle this is actually the same:

commiter:
steps 1...4 the same
5. Send a pull request to the maintainer (this is were your code review fits in)

reviewer:
1. reviews the pull request
2. pulls

Since this approach works perfectly for the aforementioned services I don't think that it should present you any problems.

Yorgos Pagles
+5  A: 

We've just started using both Mercurial and ReviewBoard at my company. We do something similar to your suggested workflow except that we don't usually bother with feature repos, and we always push to the master rather than pulling from the master.

The main issue you encounter using ReviewBoard with a DVCS is where you want someone to review a change from, say, revision 2 to revision 3, both of which are in your local repo but not in the master that ReviewBoard has access to, for example because you're still waiting for a review of the changes from revision 1 to revision 2.

ReviewBoard's solution to this is what it calls "parent diffs"; this means that instead of just uploading the patch you want reviewed, you also have to upload the diff between the latest version in the master repo and the parent revision of your patch. This allows ReviewBoard to reconstruct the origin files for the left hand side of its side by side diff viewer.

The current version of ReviewBoard doesn't support parent diffs for Mercurial, but I've submitted a patch that gets them working; I believe this should be in for RC3.

I've also patched the ReviewBoard extension mentioned in the previous post to allow it to support parent diffs. I'll make these available once RC3 is released.

Thank you for your answer, I'm going to try RC3 in the nearest time. By the way, some time ago I stumbled upon some OpenSource project(can't remember the name) where folks use ReviewBoard with Mercurial as a pre-review tool only for discussion of complicated patches. Once the patch is approved it's pulled into the repo. Trivial ones are usually pulled without any bureaucracy.
pachanga
FYI I've forked the ReviewBoard extension (having thus far been unable to contact the project owner) to http://bitbucket.org/ccaughie/mercurial-reviewboard/. This has all of my changes, including parent diff support.
Mercurial ReviewBoard extensions is now here http://code.google.com/p/mercurial-reviewboard/
yanjost
A: 

There's now an extension name FileReview which is integrated with TortoiseHg (as of TortoiseHg >= 0.9). The reviews seem to be integrated into the repository.

It didn't manage to make it work on Windows, but I hope it will be improved !

yanjost