Crucible with Mercurial changesets

[David Anderson]

Here is our situation, and i want to know if this will work with CodeCollaborator.

We use have a main dev branch, and all of our enhancements are branches off the main line. The life of an enhancement branch varies from a few hours to a few months.

During the life of an enhancement branch, it is sometimes necessary to merge into the enhancement branch from the main branch, or from another enhancement branch.

Within the enhancement branch, we do our coding, then developer testing, then code review, code review rework, QA on the branch, and then merge the branch back into the main dev branch.

So, from a code review perspective, we usually have a number of changeset's that have been committed to the branch that we want reviewed, but we don't want to review the changes made when merging up from the main branch because that has already been reviewed. So, optimally, we would like the ability to manually select a set of changesets from the branch, and have them all added to the code review, and if a file is modified by multiple change sets, the review simply shows the ending version verses the original version.

Another way of stating it:

 * branch 'feature' off of the trunk has commits A-F
 * A and B are normal commit straight to the branch
 * C is a merge commit that picks up change X from the trunk
 * D and E are more simple changes to the feature branch
 * F is another merge that picks up change Y from the trunk
 * G is more changes to the feature branch.

And we want to be able to review A, B, D, E, and G.

Fog Creek's Kiln solution does allow us to gather the changes like we desire, but I am interested to see if Crucible provides similar capabilities. I am just trying to figure out if we can consolidate enhancement branch changesets in an efficient manner using your tool.

Thank you for any information you can provide.

- David.

[Sten Pittet]

Hi David,

In Crucible you can manually pick the changesets that you would like to see reviewed. If a file has been modified in different changesets you will have the possibility to see the different types of revision via a revision picker.

Sten Pittet
Dev Tools Product Manager
Atlassian

[David Leach]

I just asked the exact same question. I don't understand the answer given by Sten though? Are you suggesting that the way to address this is to not just select the complete merge point but to instead open the file picker on the change set and select files individually?

If this is a branch that was open for a long time then you have to be careful here because I'm not sure how you identify the files you want to do this with? If, lets say, the merge of the release branch into your development branch had no conflicts then I could see where you want to avoid including those files into your code review. But if you had to do some manual intervention then yes, you need to include that code in your review because it is possible that your manual intervention was incorrect.

What I don't understand is why crucible can't automatically exclude the change information from the release branch and only focus on the changes that occur on the branch under review?

[Sten Pittet]

To be clear I wasn't suggesting to pick files, rather than that I was confirming that in Crucible it is possible to pick the changesets that you want to review. We encourage reviewing changesets as they come instead of reviewing all the changes between two branches.

That being said if you want to review the difference between two branches you can still generate the diff and upload it to Crucible to do a review.

Does that clarify my comment?

[David Leach]

So the problem we have is that we have our main branch (release branch). When a developer picks up a ticket they will create a new branch from the release branch and work their ticket. This new branch lives for as long as it takes to finish the work. When finished, the developer will present the dev branch for code review and if it passed code review (and quality tests) it can be then merged back to the release branch for general availability. This development branch is then closed.

Now because this developer branch may have been active for some period of time, we have a policy whereby the code to be reviewed has to match what will be eventually the tip of the released branch. To accomplish this, the developer may have to merge changes that occured in the release branch into their dev branch and insure that the merge is correct. Depending on the age of the developer branch, this could happen zero times (because there had been no changes to the main branch since the dev branch was started), one time (at the end of development on the dev branch), or multiple times.

So the problem we have sound similar to what this person is complaining about. We create a code review for this developer branch and select the changesets that represent this branch. If we choose a changeset that is from one of the merge points into our dev branch it seems to result in code in the review that highlights changes from other developers instead of just the changes in the developer branch.

Now I've played around a bit with the selection of changesets and tried to avoid selecting these merge points but that seems to in turn result in files being marked as "out of date". And sometimes when we do select these merge point changesets we end up with duplicate files in our code review (with one of them again showing as "out of date"). We haven't quite figured out what the right course of action is here to get the desired result, a code review that represents only the code changes from the dev branch.