(This is a modification to the original issue, which was unrelated to the issue the customer was having: The original issue has been recreated as CRUC-5237).

When a file is copied over an existing file using SCM commands (possible in git/hg/p4/svn) and the scm reports this to us, we (as of 2.4) nominate the copy source as the ancestor of the FileRevision. This means it inherits the blame of the copy source (correctly), but also, when a review is created, it uses the copy source as the default "diff parent".

In addition, another change was made in 2.4 to prefer ancestors over predecessors when considering whether a revision being added to a review - if a FileRevision has ancestors, it only checks those. Thus, adding a new revision copied over an old one after adding the old one will not get it to match the revision graph, causing the review to have 2 of the same path, one being a diff to the previous and one being a diff to the copy source, when what is really desired is a single FRX with 3 revisions in a row.

Given a revision graph like:

 C = Copy, P = PRedecessor, M = Modification

    3 --P-- 4
   /       /
  C       C
 /       /
1 --M-- 2

I see 2 possible solutions to this problem:

1. Reconsider the diff parent when we have a copy over an existing file - instead of choosing the copy source, use the predecessor - if the predecessor was deleted (no file existed at the path), we should use the copy source. To implement this, we would also have to change the behaviour of the ancestor/predecessor detection
2. Change the ancestor/predecessor detection to consider predecessors as well. This would allow the user to either:
   1. Add the 3 revision (and implicitly rev 1), then select the rev 4 - this would then add them as a single path 1-3-4
   2. Add rev 4, then edit the review and remove the implicitly selected rev 2, then add 3 (implicitly adding 1, resulting in 1-3-4