How to create a pre-push review with Mercurial?

long_at_work November 2, 2011

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

1 vote
AjayA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 6, 2011

Hi Long,

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

http://confluence.atlassian.com/display/CRUCIBLE/Creating+a+Patch+Review

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

Regards,

Ajay

long_at_work November 14, 2011

@Ajay,

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.

long_at_work November 14, 2011

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
Atlassian Team members are employees working across the company in a wide variety of roles.
November 17, 2011

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

0 votes
Gytis Greitai
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 24, 2012

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)

0 votes
AjayA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 4, 2011

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
Regards,
Ajay.
0 votes
Tom Davies
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 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?

long_at_work December 2, 2011

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
TAGS
AUG Leaders

Atlassian Community Events