Re: Moved file resolution fails

> As far as I'm aware this is all client-side behavior - nothing to do with the server. Resource move/rename
> has always been recorded as a _Delete_ of the original path and a _Copy_ (Add) from the previous path
> revision. It could be I'm missing something here, also.

As of 1.8, it now knows if an add or delete was due to a move.  For example, on my RHEL8 system that has 1.10, a move will look like this in status:

D        foo/bar
          > moved to baz/bar
A        baz/bar
          > moved from foo/bar

If I use this tree to update from even the 1.7 server, conflict resolution can find the change in the trunk to foo/bar/example.c and rewrite it to
baz/bar/example.c.  The conflict resolution gives me the option to (u)pdate the destination of the change.

However, if I check out my local branch from 1.7, the above 'moved' information is lost.  And in that case, conflict resolution fails.  There is a
published paper that 1.8+ clients implement in resolving the new path in the absence of the 'moved' information.  It involves a heuristic where
1) the delete and the add must happen in the same checkin
2) the adds will be searched for some kind of common ancestry that can be used to match the add to the delete

But whatever was implemented, the tree conflict search does not seem to find its common ancestry.  In addition, the example.c file modification
record is lost, so after resolving the tree conflict there is still an incomplete merge even though it has the merge info recorded.