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

Create a review for a branched repository

My team is using a branched repository system in Mercurial for managing branches. (This is the standard way to do things in Mercurial.) This means there is a root repository (call it "root") and features are done in a separate repository (we'll call one "featureA"). When everything is done, we pull from featureA and merge to root.

I have both repositories configured in Fisheye+Crucible, but I can't seem to find a way to create a review that contains every changeset in featureA that is not in root.

I can list the changesets locally with a command: hg log -R featureA -r 'outgoing("root")'

So if I could create a review from a list of changesets that would work. Likewise, if I could create a review from a revset, that would work, since I could find the ids and work with descendants.

How can I create this review?

2 answers

0 votes
lpater Atlassian Team May 04, 2015

While you can't currently create a cross-repository branch review (which is what you'd probably need for your use case) you should be able to manually add the changesets from the forked repository to a review (using the 'browse changesets' feature and selecting your forked repository and branch).

This should result in the review with the content that was changed by those changesets.

So, this is basically what I'm trying to do. But there are a very large number of changesets, to the point that accurately selecting them all by hand is impractical. This particular branch has gotten way out of hand, but it has to be reviewed before we can incorporate it. Crucible is considerably faster than our other review tools, if I can figure out how to properly designate it. It does look like I could upload a sequence of patches, so perhaps just patching from the outgoing would be sufficient.

lpater Atlassian Team May 05, 2015

If you go the patch route, you might also consider just making a single patch with the expected diff and reviewing that. Otherwise you might want to try using the REST api to create a review with the exact changesets you want (that you could get from `hg log` between the two repositories). Have a look at the REST docs for reviews-v1 ( you can specify a number of changeset ids to be included in the review created.

0 votes

Hi @Chris Lemmons,

Have you tried creating review for whole branch, the feature that was added in Crucible 3.6 last year?   I believe this is what you are looking for - by simply picking up a feature branch and a base branch (the branch you are going to merge changes into and most likely the branch you created your feature branch from) you can create review that would show all the changes on the feature branch that are not yet merged into the base branch. See for more details.

Hope that helps,

This is exactly the feature I want, but doesn't appear work on branched repositories. For Mercurial, it only works on named branches. What I have is branched repositories. See for an example of how this works. It doesn't appear that crucible has a way to associate a repository with an “upline” repository. Maybe I'm missing something.

As a sidenote, this sort of thing is very common in applications developed for git, but with mercurial support kinda added in later. Named branches in mercurial are only topographically similar to branches in git. Most git branches are more accurately reflected with forked repos (clones) in the mercurial idiom. Either way, though, forked clones is what I have now, so I'd like to see if I can use crucible somehow with it.

Ok, I've assumed your forked repository still contains the base and feature branches. Now I see you rather have just single branch on a forked repository, and that is your feature branch. I am afraid Crucible does not support cross repository reviews yet. Feel free to create a feature enhancement request for that in project, so we can keep watching how many customers would be interested in such feature. Hope that helps,

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events