Re: Moved file resolution fails

[Stanimir Stamenkov via users]

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:

Dfoo/bar
   > moved to baz/bar
Abaz/bar
   > moved from foo/bar
[...]


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

"Working copy records moves as first-class operation" 



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



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

Re: Moved file resolution fails

[Johan Corveleyn]

On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users
 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:
> >
> > Dfoo/bar
> >> moved to baz/bar
> > Abaz/bar
> >> moved from foo/bar
> > [...]
>
> O.k.  I've now looked it up:
>
> "Working copy records moves as first-class operation"
> 
>
> 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).
> > 
>
> 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

Re: Moved file resolution fails

[Stanimir Stamenkov via users]

Fri, 2 Feb 2024, /Johan Corveleyn/:

On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users wrote:

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

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


Thank you for the references and additional info.  I have to admit I'm 
using Subversion just when absolutely necessary, since quite some time 
now.  And then I'm not the OP with the problem.  In this regard I 
haven't tested extensively whether and how svn merge with moved files 
may have improved, but here's an example from ~1.5 year ago using 
Subversion 1.14:


https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17582731&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17582731

(there's a "svn-merge.log" link to an attachment with the full session)

The example performs a cherry-pick (back-port) merge:

svn merge -c  ^//branches/

It doesn't seem to notice the source has once been renamed from the 
target, and doesn't perform automatic merge.  Maybe this one is specific 
to cherry-pick merges?


I've now tried simplified scenario described by the OP – it does appear 
to automatically merge updates to a moved file (this is a Windows 
Command Prompt):


> svn info
Path: .
Working Copy Root Path: C:\...\svnwork
URL: file:///C:/.../svnrepo/branches/feature-1
Relative URL: ^/branches/feature-1
Repository Root: file:///C:/.../svnrepo
Repository UUID: 9f01a344-90b5-c945-b13b-67a67f39ca98
Revision: 5
Node Kind: directory
Schedule: normal
Last Changed Author: stanio
Last Changed Rev: 4
Last Changed Date: 2024-02-02 15:32:09 +0200 (пет, 02 фев 2024)

> svn merge ^^/trunk
--- Merging r3 through r5 into '.':
   C foo
--- Recording mergeinfo for merge of r3 through r5 into '.':
 U   .
Summary of conflicts:
  Tree conflicts: 1
Searching tree conflict details for 'foo' in repository:
Checking r4... done
Tree conflict on 'foo':
Changes destined for a file arrived via the following revisions 
during merge of

'^/trunk/foo:3-5':
 r2 by stanio, r5 by stanio
No such file or directory was found in the merge target working copy.
The file was moved to '^/branches/feature-1/fou' in r4 by stanio.
Applying recommended resolution 'Apply to move destination':
Gfou
Tree conflict at 'foo' marked as resolved.
Summary of conflicts:
  Tree conflicts: 0 remaining (and 1 already resolved)

--
Stanimir