Mercurial and code reviews; good workflow?

I'm in a small distributed team using Mercurial for a central repository. We each clone it via ssh onto our own linux boxes. Our intent is to review each others' work before pushing changes up to the central repository, to help keep central's tip clean. What is a good way to share code between developers on different linux boxes? I'm new to Mercurial. The options I can think of (through reading, not experience) are:

1: Author commits all local changes and updates working clone with central's tip. Author uses hg bundle, if there's a way to specify which local revs to include in the bundle. (an experiment showed me "bundle" only grabs uncommited changes, even if there are previous local commits that central doesn't know about) Author gets bundle file to reviewer. Reviewer creates a new clean clone from central's tip, and imports the bundle into that clone. or,

2: After both author and reviewer fetch from central's tip, author uses patch and reviewer imports the patch. or,

3: Author pushes to reviewer or reviewer pulls from author (but how, exactly? What I read is only about pushing and pulling to/from the original served repository, and/or on the same box instead of between different linux boxes.)

4: Forget reviewing the code prior to pushing to central; go ahead and push, using tags to identify what's been reviewed or not, and use Hudson (already working) to tag the latest safe build so team members can know which one to pull from.

If your team uses Mercurial and does c开发者_运维知识库ode reviews, how do you do get the reviewer to see your changes?

Most of these are possible, some are more tedious than others.

1. You can use bundle by specifying the tip of the central repo as the --base:
   hg bundle --base 4a3b2c1d review.bundle
2. Might as well just use bundle. That way, the changeset data is also included.
3. You can push (and pull) to (from) any repository that has a common ancestor(s). If you want to pull from one of your colleagues, they just need to run hg serve on their machine, and you will be able to pull.
4. This also works, but you will have to maintain multiple heads and be careful about merging. If you don't, it can become easy to base a stable change on top of an unreviewed changeset, which will make it hard to undo if you need to fix that unreviewed changeset later.

Of the options you presented, #1 and #3 are probably easiest, just depending on whether or not you can reach each other's boxes.

On a related note: This is the question that got my colleague and I started on developing Kiln, our (Fog Creek's) Mercurial hosting and code review tool. Our plan, and the initial prototype, would keep multiple repositories around, one "central" repository, and a bunch of "review" repositories. The review process would be started by cloning the central repo into a review repo on the server, and then running a full repo diff between the two, with a simple web interface for getting and viewing the diffs.

We've evolved that workflow quite a bit, but the general idea, having a branch repo to push unreviewed changes to and an interface to review them before you push them into the central repo, is still the same. I don't want to advertise here, but I do recommend giving it a try.

Half answer to this question is using ReviewBoard with Mercurial extention. It allows to push certain revisions for review by issuing the following command

hg postreview tip

I'll add a 5th option - do all development work on named branches, preferably one per task. Allow anything to be committed to a "development" named branch, whether it's in working state or not.

Push to the central repository, have reviewer pull the branch. Perform the review on the branch.

When the review has passed, merge the development work into the appropriate feature branch.

This workflow, which is (to me) surprisingly unpopular, has many advantages:

1. All work gets committed - you do not have to wait for a review to be done before committing.

2. You will not build off the wrong version. You only ever build from the feature branch.

3. In-progress work does not interfere with other developers.

4. From the development branch, you can either look at the latest changes (e.g. the changesets addressing review comments), compare with the branch point, or compare with the latest feature branch - all of which can give useful information.