You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We have a usability issue with Crucible. In our organisation people make small frequent commits to the same files in SVN. Let us say that for the code review we need revision 10 and 19 of the same file. In between other people have committed something that is not related. Now the diff file is also showing the commits done in between. Is there any way to only show diffs for commits 10 and 19 and ignore commits 11-18.
This is currently not possible, and nor would it really make sense, I believe, because you need to be reviewing the change made by developer A in revision 19 within the context of those changes made in revisions 11-18 by developer B.
Maybe you need to consider breaking up that class or restructuring your code so unrelated changes can be excluded at the file level, rather than on a per revision basis ?
we have the same issue and on some projects it makes Crucible unusable.
I understand that I need to see revision 19 in context with changes 11-18, but in Crucible I can not recognize what really changed in 19 a what changed in meantime in 11-18. It looks like all revisions 10-19 are part of this review, but in fact the revisions in between belongs to another review made by another author.
If I want to comment some changes I don't know if this is the right review and right author..
I our case it's not problem of big files, it's more about workflow. One developer commits code, creates review, another developer commits changes in same files and creates another review. I would say it's pretty common workflow.
But reviewer of first review can not distinguish those two commits.
If I could downvote that answer, I would. Shouldn't it be customers who decide what makes sense for their project? Since reviews are typically for the purpose of reviewing changes associated with a specific change request rather than a whole file, of course it makes sense to filter on only the changes that were checked in as part of the commits that were included within the review. There isn't even an easy way to mark the differences appropriately. If I add comments to a change that the author of the review didn't make, then they will be rejected and everyone has just wasted their time. The way that crucible works does not fit into a workflow where you have a lot of different commiters who are working on different change requests.
The suggestion of splitting up files is preposterous. Sure, customers will simply redesign their code in order to accomodate a tool. Okay.
this topic came up in a group discussion today and I see that discussion appears to have stagnated. before we incorporated Fisheye/Crucible, we were using ReviewBoard – the workflow that tool wants to use is pre-commit reviews. we wrote some tooling to trigger on commit to generate the diff and upload it...we encountered the same issue reported here, where the diff would often pull in revisions we hadn't anticipated, so the script was altered to specifically diff against the last revision for the file, at commit time. this allowed multiple specific changesets to be added to a single review with only the authors changes highlighted. note: the issue here is not that we see intermediate commits in the review context, its that they're highlighted and the reviewer can be easily confused by the changes or spend time reviewing code that is not in their purview for the given change.
we have discussed potentially writing scripts like we used to have in order to automatically file patches to create/update our reviews to get around this (not ideal) or potentially request that Crucible use a different highlight for non-author changes or possibly add a filter option so that (at least initially) the reviewer can focus on the author's changes. I definitely want to see intermediate revisions in the context, I just don't want it to show up in red and green as if it were changed by the author (as a reviewer).
The answers convinced me not to purchase a license for our team. As the team member chosen to find a good code review tool, I convinced my team to use Crucible, which we have on the evalutaion license. I received the go ahead on starting the purchase order, but found this snag when I setup a code review. Other developers on the team alerted me to the issue some time back, but, I believe it was a setup issue. Now that I know, my team will be searching for another tool and not using Crucible. So, not only did this "feature" loose a license purchase, but also long term license renewals. Let me know when you fix this "feature", it seems to be the only, but worst, issue we've had with Crucible.
Crucible will always show a contiguous diff for changes on the same path and branch. This is why the intermediate revisions are included.
In Pavel's example above, when developer A creates a review for commits 10 and 19, Crucible will create a diff view with starting revision 9 to 19. As you point out, this will include diffs between 9-10 and 18-19 (developer A's changes) but also 10-11, 11-12 etc (developer B's changes).
Crucible will show author & revision annotations, so reviewers will at least be able to see which authors are responsible for each individual diff hunk.
From your description, you'd prefer Crucible to create a non-contiguous pair of diffs for the file; just 9-10 and 18-19, so that only diff hunks from developer A are included.
Is this correct? It's something we could consider.
I suspect we don't get this feature request much because most customers are using private branching to a avoid this kind of problem.
even with the feature branch approach we do occassional updates from the parent/master branch to keep up to date, and I yet need to figure out how crucible would represent such a commit; that is: can I see, recognize, and diff all the commits the dev made and distinguish that from what the update from parent brought in? (It's a pity that it isn't exactly documented how a commit selection in a review turns out be shown in the actual review.)