Hello everyone!

After analysis we decided that we will use the "Added / Modified" label to show whether the file has been added+modified or only modified between revisions. We do not want to clutter the revision slider with even more data. Therefore, please watch CRUC-6671 for further updates.

Kind regards
Marek Parfianowicz
Development Team Lead

Note:

Adding a visual indicator for the added file could be done together with the fix for added/modified labels to have more consistent behaviour (CRUC-6671).

For a related Jira issue CRUC-6312  there is a discussion on this. Hopefully Jira can reopen it and implement a suitable solution.

It is 2016, my team is using Crucible for 2 months now and i have just realized this problem. I am sad that i found this issue open and another (CRUC-6312) already closed unresolved!

So to catch up on this problem, i try to explain it from my point of view:

When i modify a file which exists in the file system for ages, then i have a start point. Then i do some "a" stuff then i commit as revision "A". Then i do another "b" stuff and i commit as revision "B", ... When i check what happened with my file in crucible, i can see that there were changes a + b + c by selecting the piont A <-> C.

When i add a new file to the file system with some content, that is commit "A" with modifications "a". Then i do some changes and make some commits. What i would expect from Crucible is that when i select points A < - > C then i get modifications a + b + c. Instead if i select only commit "A" then it shows correctly all "a" modifications. Although when i select A < - > C then it shows only b + c which is - from my point of view - a bad practice. The only notification where from i should realize there is a modification in "a" is that the name of the file is green representing it is a new file.

All the time i was reviewing i thought the part of the code that i should review are the parts highlighted green. As for this example, this is not true at all. Probably we have skipped couple of lines of reviews because this.

I hope explanation is ok so more people can realize what is the problem here. I am also suggesting to all the reviewers to be aware when reviewing a new file. Also waiting for a fix.

> This now seems to be the default, in Version:3.1.4 Build:20131008122028 2013-10-08.

Oh, false alarm, sorry. I've just had a review this morning where I wasn't shown all changes by default.

> the default result seen by a reviewer when they first visit a review must tell the reviewer that the file has been added in this review, and must show them the full contents of the file without them needing to adjust any controls.

This now seems to be the default, in Version:3.1.4 Build:20131008122028 2013-10-08.
The file is still shown as blue rather than green, but at least I see all changes by default, which is far better than the old behaviour.

Did someone partially fix this?

(There is also a secondary issue around the API not distinguishing between these two cases, see e.g. CRC-6270)

The core problem is that, in the add + modify case, reviewers are not shown all changes by default. If they review the code as shown to them by Crucible, then they will be signing off code they haven't actually seen. This is a critical bug.

Any solution which still requires reviewers to be aware of this bug/quirk and to check for it on each reviewed file is not really a fix. The current title of this issue, "Indicate in the revision selector when a revision has been added", will not suffice as a fix. Even with that fix in place, reviewers would need to be aware that, if the first revision for a file was an add, and if that add is part of this review (i.e. PRD-8 not PRD-9 as above – how can they determine that?) then they need to move the slider around to see all changes.

The problem actually runs deeper than that, because the plugin API does not distinguish between these cases either.

To distill the problem, imagine two changesets:

• changeset 37 adds a new file src/A.java
• changeset 38 modifies src/A.java

and two Crucible reviews:

• review PRD-8 contains both changeset 37 and 38
• review PRD-9 contains only changeset 38

Both of the reviews appear identical to the reviewer.

Crucible defaults to showing the diff from 37 to 38 which misleads the reviewer of PRD-8, so that they may not look at changeset 37.