Crucible review will occasionally display two versions of the same file?

[David Leach]

I find this somewhat frustrating and haven't figured out what causes or how to fix it. We use mercurial and sometimes when I add files to a review I'm creating the file list will end up with two versions of one of the files where the change sets are spread between the two files instead of having a single file with all of the change sets.

For example, I currently have a review I've created and a file is duplicated in the review where one version has change sets 628, 648, 650, and 651. The other version of the file has change sets 644 and 649.

I will say that this is a branch and I had merged changes from our main branch into this branch which may have something to do with this.

So what is causing this and what should I do to fix it?

Let me also add that one file show as "File Outdated" on the right top menu (where View and FishEye are).

[seb]

This can sometimes happen when adding a changeset which includes a merge, or when the changeset has revisions which are not on the same ancestry line as the files which are already in the review. This is unfortunate, and a case which Crucible doesn't handle very well at the moment. Let me explain:

Consider "file.txt" which has the following revision graph:

3 ----- 4 ----- 5
           /       /
          /       /
         /       /
0 ----- 1 ----- 2

If you review contains changeset "2" (ie, the diff from 2:1), and then you add the change made in the merge commit (rev 4) then Crucible can show doubled files. This is because Crucible will choose the first parent (4:3) to add to the review (this is a bug), and revision 3 is not on the same ancestry line as revision 2 (the latest revision of file.txt in the review). In order to show all the revisions, we currently show the file duplicated as a way to ensure that the reviewer can see all the relevant diffs. The logic to view the files in Crucible isn't wrong - but rather adding the revision is incorrectly done.

I believe a workaround is to manually edit the review and remove the revision "3" from the review and refresh the page. I think that will cause Crucible to correctly render the lineage diff of 4:2:1 rather than 4:3 and 2:1. (nb: I haven't tried this recently)

We are currently tracking this bug at https://jira.atlassian.com/browse/CRUC-5229 where you can vote for it or add your feedback.

Thanks,
Seb

[David Leach]

Seb, Not sure you saw my message below (I should had added it as a comment to your message but instead it got added as an "answer" which it isn't). I would appreciate it if you could consider the comment and give me a response. We have developers that are quite frustrated with the crucible tool to the point of suggesting that we start looking at alternatives but I would prefer to stick with this tool because of the integration with Jira, which we use.

[Eric Roberts]

This issue seems to be related https://jira.atlassian.com/browse/CRUC-6568.

[David Leach]

First, thank you for the response.

What happens then with the following:

3 ----- 4 ----- 5 ----- 6

/ /

/ /

/ /

0 ----- 1 ------------- 2

is it still the case where I need to remove 3?

And does this further have a problem if we have a branch where there were periodic merges from a main/release branch into the development branch... does it end up needing to remove each of the merge points from the review?

4 ----- 5 ----- 6 ----- 7 ----- 8 ----- 9

/ / /

/ / /

/ / /

0 ----- 1 ------------- 2 ------------ 3

[David Leach]

So no one has any comment on this? Do I need to go the official ticket route?