Crucible supports iterative (cumulative, or incremental) reviews for both post-commit and pre-commit reviews. This allows you to update the review with new versions of files, and changesets (for post-commit reviews) or patches (for pre-commit reviews) that have been created after the review was started.

Iterative reviews allow your team to discuss changing code in the context of a single review. This lets the reviewers see all the related changes together, and to more easily keep track of comments and defects.

On this page:

Iterative post-commit reviews

To set up an iterative post-commit review, you create a review, and add content to it, in the usual way. Crucible automatically recognises when files under review have been updated in the repository, and provides the option to add the revision to the review.

 

See Viewing diffs below for information about the slider and diffs.

Iterative pre-commit reviews

Pre-commit reviews make use of patch files that are uploaded to a review. Crucible allows revisions of patch files to be uploaded to the review, and can display diffs for files in the patches. This allows your team to set up and perform iterative pre-commit reviews. 

See Creating patch files for pre-commit reviews.

Initial patch upload

When uploading the initial patch for a review, Crucible must be able to anchor the patch to a repository if you subsequently want to upload patch iterations. If Crucible is unable to anchor the patch to a repository, you will only be able to upload the patches as separate files.

You upload the initial patch for a review in the usual way – see Adding content to the review.

Iterative patch uploads

When you add a new iteration of the patch to the review, you can choose which previously uploaded patch it is a revision of. The new patch must be anchored to the same repository as an existing patch.

Note that you cannot add unanchored patches, even if they include full-context diffs. You can include an unanchored file in the anchored patch, however Crucible is unable to provide full context for that.

Viewing diffs

Crucible allows the reviewer to see the different revisions of a file within the same review. The 'slider' in the file view allows you to interactively select which revisions are compared in the displayed diff, and to see the full source content. Comments are connected to, and displayed with, a specific revision. This allows you to review every change that has occurred on a code file over a given range of commits, and lets you see the evolution of the file through various revisions (all within one Crucible review).

These screenshots show how, for a post-commit review, you can drag the slider 'handles' so as to display just the changes in the last commit:

Drag the 'handles' to the same commit to see the full source of that version of the file.

 

When viewing patch files in a pre-commit review, the slider displays the diff for the selected iterations, in a similar way to that for post-commit reviews. Each patch iteration is referred to as a 'working copy'.

 

Attachments:

Comments:

After initial review, reviewers click "complete". When author of the review starts the next iteration, all reviewers are already in "complete" state and the author can't tell which one of them has done the review for the second time and which one not.

Question: Can you make the tool to send automatically mail to reviewers when next iteration in review has started and change the state of the reviewers to "under review" state?

Posted by at Aug 12, 2013 11:04

There seems to be no work-a-round for this problem. You can't "uncomplete" the reviewers even manually (but you can send a reminder mail manually). CRUC-6078 and CRUC-6047 might be related to this.

Posted by at Aug 12, 2013 11:18

If the patch contains several files and only one of them has changed between iterations, it is hard to see which file that is. Currently only way is to view all files one by one. Is it impossible to move the slider from being file specific to patch specific, so that changing the slider will make e.g. some files disappear, if those files contain no changes between those iterations?

Posted by at Aug 12, 2013 11:58

While the slider is easy to use after learning how it works, learning how it works is not very intuitive. This is probably caused by the look of the slider. The slider does not look like something that could be moved around.

Posted by at Aug 12, 2013 12:00

I am finding it very difficult to use Crucible for iterative reviews. As a reviewer, if I want to reject a change, there is no direct option. I can give the comments and leave the review open or I can "complete" the review. Completing does not sound the right thing, because then I lose track of which reviews I approved and which ones I rejected. So I just enter the comments and tell the developer over email that I am done reviewing and I don't approve the change. She then does some rework, updates the review, but Crucible does not tell me when I should start reviewing again. She sends me an email to ask me to re-review. This cycle continues two or three times sometimes. Imagine the pain when I have 15 to 20 such review requests open at a time!

Is there any way out than moving to another review tool? Does anyone use Crucible for code review in a real, large, active development team, especially a geographically distributed one?

 

Posted by at Sep 05, 2013 09:03