Re: Moved file resolution fails

Fri, 2 Feb 2024, /Sands, Daniel N./:

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

O.k.  I've now looked it up:

"Working copy records moves as first-class operation" 
<https://subversion.apache.org/docs/release-notes/1.8.html#moves>

Note the "working copy" (client-side):

> Limitations:
> 
>   * Moves are recorded as such only within the working copy. The link 
> between the copy and the delete is established only when a local move 
> operation is performed, and is lost upon commit. The committed revision 
> will show a copy and a delete, instead of a move.

It is unclear to me whether the move info is retained in the source 
working copy after the commit, but is likely:

> Known issues:
> 
>   * Tree conflicts involving replacements are currently not detected 
> when updating a moved file or directory (see issue #4318). 
> <https://issues.apache.org/jira/browse/SVN-4318>

At the end:

>   * Tree conflicts flagged by svn merge cannot be automatically resolved 
> yet. This will be addressed in a future release.

If I understand correctly, not much has changed related to merging 
with/into moved files.

-- 
Stanimir