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
