Reopening (WONTFIX was always the wrong resolution anyway).
Perhaps I don't understand this fully, but I don't believe that this is
conditional on issue 898 (true renames) at all.
As I understand it, we have a change on trunk that looks like:
Add /trunk/newfile (copied-from /trunk/oldfile@rX)
And when we merge that to /branch/esfoo, we get this change:
Add /branches/foo/newfile (copied-from /trunk/oldfile@rX)
i.e. the fact that we 'renamed' oldfile to newfile on trunk has been lost, and
we've ended up replacing the file on the branch with one from trunk.
I don't think that this is conditional on us getting a real rename operation.
When we do, the original change on trunk will look something like:
Rename /trunk/oldfile to /trunk/newfile
And we'll need to merge that as
Rename /branches/foo/oldfile to /trunk/foo/oldfile
However, we can get exactly the same behaviour by adjusting the copyfrom source
in the A+D case - while that won't solve the general problem of merging a rename
over a locally-modified file, that's _not_ what was being asked for here.
Original comment by malcolm