Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to create a pre-push review with Mercurial?

Let''s say I have a bunch of patches related to the same feature being implemented in my Mercurial MQ or I have a bunch of outgoing changesets also related to the same feature being implemented (so I would like to have them all part of one single review). I would like to review them before really pushing all of them to the central repository. How do I do that with Crucible?

4 answers

Hi Long,

You can create an pre-commit review by uploading a patch to Crucible:

You can upload the patch to Crucible and anchor it to your repository before commiting the changes to your repo.




I think you don't quite understand my question.

Let me explain again.

In the SVN/CVS Centralized version control world, each commit will go immediately to the central CVS/SVN repository. So before the user commit, he/she can upload the diff of that **single** commit to Crucible for review. So your proposed solution works in this case.

Mercurial is a Distributed version control. Commits only go to the local repository, not to the central repository. There can be many commits to the local repository before the user decide to push all of them to the central repository. So in this case, the user will want to review **all** the commits (so multiples diffs here, not one single diff) before pushing to the central repository. The user also wants all the diffs to be part of one single review because they are all related to the same feature/bug. So your proposed solution doesn't work in this case.

So maybe another way to phrase my question is what's Crucible support for distributed version control system? Make sure you understand what a distributed version control system means.

After further experiementation, I seem to be able to create a post-push review from multiple commits. Simply select "Create Review", then "Browse Changesets", then select the proper repository, then put a check-box in the changesets I want to be part of the same review. Patch anchoring works for all the files being reviewed. That's great but has a major annoyance that I have no idea which file is coming from which commit.

However, creating a pre-push review with multiple changesets is not that great.

Here's the setup:

- hg update default (update my curent mercurial working directory to the tip of branch default, the central repository also has this tip)

- make some modifs, hg ci -m "some comment" (creates cset1 that has changes relative the tip, so tip is the parent of cset1)

- make some modif again on top of cset1 and hg ci -m "some comment" (creates cset2 that has changes relative to cset1, so cset1 is the parent of cset2).

- hg diff -r cset1 > cset1.diff; hg diff -r cset2 > cset2.diff

- create a pre-commit review, uploading both cset1.diff and cset2.diff.

The review contains both diffs but none of them can be anchored. Trying to anchored cset1.diff to the tip (tip is a changeset that already exist on the central repo of Fisheye) doesn't work, don't know why.

Then of course there's no way to anchor cset2.diff to cset1.diff because cset1.diff doesn't exist yet on the central repo.

So no patch anchoring at all for the pre-push diffs. The major annoyance for post-push review described above also applies to this pre-push review as well.

I hope it is now clear what my problems are. Please let me know if there's any workaround.

Tom Davies Atlassian Team Nov 17, 2011

Long, I don't understand your two hg diff commands -- won't cset1.diff include all the changes in cset2.diff?

But I think the best DVCS practice is to create a branch for the work involved in fixing a bug, then push whenever you like and create reviews of the changesets on the branch. When you're happy, merge the branch to default.

If this was git .. yes. But mercurial support for branches kind of .. sucks (you can only close them, and for bookmarks you have to have extension installed)

Hey Long,

easier to review

Fair enough, I see where you're coming from but as per Tom's comment, you can only apply a patch to the latest version.
There is a feature request to create reviews between arbitrary versions in Crucible
0 votes
Tom Davies Atlassian Team Nov 17, 2011

If you don't mind the net result of all the changes you've made being what is reviewed, you can just create a diff between the most recent revision in your repo and your most recent change.

But I think the best DVCS practice is to create a branch for the work involved in fixing a bug, then push whenever you like and create reviews of the changesets on the branch. When you're happy, merge the branch to default.

There are two things Crucible doesn't do:

- anchor patches which are not relative to the most recent revision in the repository

- keep two commits distinct when they are included in the same review

I understand why you want to do the former, but why do you want two review two changests which are (presumably) part of fixing the same bug independently? Isn't it the net change that should be reviewed?

Multiple small meaningful concice patches are

- easier to review

- show the logical progresssion until the final solution

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

Online AMA this week: Your project management questions answered by Jira Design Lead James Rotanson

We know that great teams require amazing project management chops. It's no surprise that great teams who use Jira have strong project managers, effective workflows, and secrets that bring planning ...

168 views 1 6
Read article

Atlassian Community Events