How to filter changes for all files by commit SHA in Crucible?

[mstanescu]

Hi all,

I was evaluating Crucible as a tool for review and i got annoyed for the folowing reason.

i created a review with 10 commits.

Crucible seems to squash all the changes in one and try present them like that but i do not like this approach because my commits are nicely split between refactorings and change of logic so that the refactorings do not cluther the review.

I know there is a slider of commits but i can only apply it to a file and not whole files.
I know i can create multiple reviews but thats just another type of cluther.

In the end what i need is to do a review in a commit-by-commit fashion or squashed if i want to.

This is somehow a show stopper for me. Anyone knows any way i can do what i describe here?

Thank you

Mihai

[Stefan Chipilov]

My team is evaluating Crucible and we find mstanescu's suggestions relevant for us, as well.

Has there been any progress on this?

EDIT: Apologies, I didn't mean to add this as an answer, just wanted to see if there are any updates.

[Piotr Swiecicki]

Hi Mihai,

If the changes were unrelated and you made different changes in each commit, perhaps you could consider raising separate review for individual commits (or for set of commits if some of there were related to each other)?

Kind regards,
Piotr

[mstanescu]

Hi,

They are not unrelated (they are tagged with same jira issue). We cannot assume a jira task will have only one commit. Lets say some are refactorings on which the next commits are based. You cannot take them out of context. One has to follow the flow. Progresively. Its much easier to review than giving 50 changed files for review. Also they will go together in production.

Creating separate 10 reviews has certain drawbacks

1. cluthering

2. lots of manual work to create them

3. might be reviewed in inorder.

Crucible should be more flexible and let the reviewer the power to combine commits as he/she pleases and not squash them by default IMO.

[Nick]

What if a reviewer spends time reviewing the changes in Changeset #1, however this code is then later refactored (or even deleted!) in Changeset #9.

That reviewer has wasted a lot of time, and mental energy reviewing Changeset #1, when all that really matters is the net effect of all the changesets applied. This is the reason Crucible 'squashes' the changesets as you mention.

Alternatives if you really feel this is vital are:

• Use a single review per changeset. You mention this has drawbacks.
• Use changeset "discussions". See the chat icon on each changeset in FishEye.

[mstanescu]

I cannot say this approach does not have some advantages but also is no silver bullet. Also Crucible right now does have a slider to select a subset of commits however only applies to current file. Won't be that horrible to make it for all i guess, more persistent between files. You already have some of the feature i need its just that is cumbersome.

What i am proposing on the short term is this

Make the slider/bar to filter commits not per file but per review and based on this filter the file tree and also the source code.

Now from the sci-fi solution this is how i see this software (has to give maximum flexibility to reviewer and maximum transparency.

Must have features

1. Creating a review does not manipulate commits in any way. Its just a collection of commits to be review. Thats it.

2. Reviewer can group/ungroup in anyway he/she pleases. Maximum flexibility. This must be reviewer choice and not developer choice.

3. Reviewer must clearly and quickly be able to see the commit message (this is an important piece of information and gives insight on the changes inside)

I've done "many many" reviews without crucible. Just with qgit. Sometimes i need to squash commits , something its nice not to do it.