On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users <users@subversion.apache.org> wrote: > > 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.
Oh yes, a lot has changed since 1.8 (which is EOL for a long time already). Actually, the major improvement came client-side in version 1.10, with the interactive tree conflict resolver [1]. This uses a lot of information from both working copy and repository to figure out what the sensible options are in case of a tree conflict, and attempts to resolve some of those automatically. You should upgrade your clients to _at least_ 1.10 to have a reasonable experience with tree conflict situations. After 1.10 lots of bugfixes and improvements have been made to the tree conflict resolver, so I would recommend to go for 1.14 (which is actually the only supported version ATM [2]). You are of course free to discuss and seek help on this list for older versions, but to me it makes no sense to complain about 1.8's client-side tree conflict handling, when 1.10 and 1.14 perform so much better in this regard. Note also that: - Even with 1.14, the information that you showed above about a move in your working copy (with the "> moved to" and "> moved from" details) is not transferred to the repository. After committing, the repository (server) does not keep the same information (it does have the "copyfrom" information in the Add, but that's it). - So when looking at such a commit, or checking out and verifying history, you cannot get the same ">moved to" and ">moved from" information, because it is simply not there. - Despite this, the tree conflict resolver in 1.10+ is in most cases able to match deletes and adds-with-copyfrom to deduce they are probably a move, and uses this kind of information to make a good guess about what needs to go where. It seems to work out fine in practice in most cases. [1] https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver [2] https://subversion.apache.org/docs/release-notes/#supported-versions -- Johan
