> 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.
