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).
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.
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.
First, thank you for the response.
What happens then with the following:
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?
We know that great teams require amazing project management chops. It's no surprise that great teams who use Jira have strong project managers, effective workflows, and secrets that bring planning ...