Crucible review will occasionally display two versions of the same file?
Asked by 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).


Answers:
author: seb
body: 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

comments: author: David Leach
body: 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.


author: Eric Roberts
body: This issue seems to be related [](https://jira.atlassian.com/browse/CRUC-6568.)<https://jira.atlassian.com/browse/CRUC-6568>.


author: David Leach
body: 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 |


author: David Leach
body: So no one has any comment on this? Do I need to go the official ticket route?