Re: Re: [EXTERNAL] Re: Moved file resolution fails

[Nathan Hartman]

On Thu, May 30, 2024 at 5:09 PM Sands, Daniel N. via users <
users@subversion.apache.org> wrote:

>
> On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
> > On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> > > [You don't often get email from nka...@gmail.com. Learn why this is
> > > important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
> > >  wrote:
> > >
> > > > So lesson learned:  Always make a pristine copy of the trunk
> before
> > > > making ANY changes, so that there is a revision to fall back on
> > > > where
> > > > the two branches exactly match.
> > >
> > > That's what tags are for!
> >
> > I'd heard of tagging but wasn't sure how to do it since I'm not
> > responsible for the releases... but it looks like you tag by using
> the
> > copy command.  Even worse, the text under "complex tagging" shows
> > copying your working directory to a new repo, which is what breaks
> the
> > file move/rename detection.
> >
> > On a further note, my real repo has 260 moves due to source tree
> > restructuring.  There were 290 deletions.  The current move detection
> > algorithm is an O(n^2) search to find all moves, where it ends up
> > querying the SVN server 260*290 times for merge info, per file
> > conflict.  Perhaps it would be a good cost savings to cache the merge
> > info for each file during the search, so that there are O(n) trips to
> > the server and everything else is resolved locally?
> >
> I came up with a patch for this issue.  It cuts the resolve time down
> from literal hours in my case, to less than a minute.  I can't say it's
> production ready, but it's a template at least.
>
> It attacks the core of the problem, where every time it comes up with a
> candidate pair to check, it downloads the history from the repo on each
> file.  This happened for the same left-side file hundreds of times
> while it tried each candidate right-side file.
>
> The patch leaves in (commented-out) printfs to show the problem in
> action.  The other part is, now that I have to persist data as long as
> the client context, do the temporary results pools get used for
> anything at all?  Finally, there is one change to a public API that
> would need to be fixed.
>
> >
> >
>


Hi,

Any chance you can send your patch uncompressed, with an extension like
".patch.txt"?

Thanks,

Nathan

RE: Re: [EXTERNAL] Re: Moved file resolution fails

[Sands, Daniel N. via users]

On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
> On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> > [You don't often get email from nka...@gmail.com. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
> >  wrote:
> > 
> > > So lesson learned:  Always make a pristine copy of the trunk
before
> > > making ANY changes, so that there is a revision to fall back on
> > > where
> > > the two branches exactly match.
> > 
> > That's what tags are for!
> 
> I'd heard of tagging but wasn't sure how to do it since I'm not
> responsible for the releases... but it looks like you tag by using
the
> copy command.  Even worse, the text under "complex tagging" shows
> copying your working directory to a new repo, which is what breaks
the
> file move/rename detection.
> 
> On a further note, my real repo has 260 moves due to source tree
> restructuring.  There were 290 deletions.  The current move detection
> algorithm is an O(n^2) search to find all moves, where it ends up
> querying the SVN server 260*290 times for merge info, per file
> conflict.  Perhaps it would be a good cost savings to cache the merge
> info for each file during the search, so that there are O(n) trips to
> the server and everything else is resolved locally?
> 
I came up with a patch for this issue.  It cuts the resolve time down
from literal hours in my case, to less than a minute.  I can't say it's
production ready, but it's a template at least.

It attacks the core of the problem, where every time it comes up with a
candidate pair to check, it downloads the history from the repo on each
file.  This happened for the same left-side file hundreds of times
while it tried each candidate right-side file.

The patch leaves in (commented-out) printfs to show the problem in
action.  The other part is, now that I have to persist data as long as
the client context, do the temporary results pools get used for
anything at all?  Finally, there is one change to a public API that
would need to be fixed.

> 
> 



svn-1.14-3.cache.diff.xz
Description: svn-1.14-3.cache.diff.xz

Re: [EXTERNAL] Re: Moved file resolution fails

[Johan Corveleyn]

On Thu, Feb 15, 2024 at 7:32 PM Sands, Daniel N. via users
 wrote:
...
> On a further note, my real repo has 260 moves due to source tree
> restructuring.  There were 290 deletions.  The current move detection
> algorithm is an O(n^2) search to find all moves, where it ends up
> querying the SVN server 260*290 times for merge info, per file
> conflict.  Perhaps it would be a good cost savings to cache the merge
> info for each file during the search, so that there are O(n) trips to
> the server and everything else is resolved locally?

I don't know the tree conflict resolver code very well, so I'm not
sure if it works that way, with O(n^2) calls. But it's definitely a
good suggestion / idea to look closer into those calls and trying some
strategies to optimize things.

Would you have time / be able to dig deeper and try some things in the
code yourself, maybe come up with a patch [1], or a proposal / idea in
pseudo-code (best sent to d...@subversion.apache.org for discussion)?
These days the SVN community is completely volunteer-driven, so any
help is more than welcome :-).

[1] https://subversion.apache.org/docs/community-guide/general.html#patches

-- 
Johan

Re: Moved file resolution fails

[Johan Corveleyn]

On Wed, Feb 14, 2024 at 11:00 PM Sands, Daniel N. via users
 wrote:
>
> >
> Okay, I finally figured out how to trip up SVN:
>
>
>
>
> > > I built my own experiment which I'll try to reconstruct here:
> > > mkdir test
> > > mkdir test/foo
> > > mkdir test/foo/bar
> > > mkdir test/baz
> > > echo "a" > test/foo/bar/example.c
> > > svn import test svn+ssh://theserver/var/svn/playground/test
> > > rm -rf test
> > > svn co svn+ssh://theserver/var/svn/playground/test
> > > cd test
>
> Now I did something that SVN apparently doesn't like:
>
> svn mv foo/bar/example.c baz
> svn cp . ^/playground/test2

Hm, that's quite an atypical set of operations. The first command
makes a local move in the 'test' working copy (without committing that
move), and then creates a branch-from-WC with a local modification in
it. Creating a branch from a working copy is a bit special, precisely
because it may carry along local mods that are not committed to the
branch source. This is translated by SVN into copy of the branch
source, with the local modifications injected "on top". If you 'svn
log -v' the revision that created that branch I think you'll see
something like this:

A + /playground/test2 (from /playground/test:XXX)
D/playground/test2/foo/bar/example.c
A + /playground/test2/foo/baz/example.c (from
/playground/test/foo/bar/example.c:XXX)

As you can see, the Deleted file is different from the "copyfrom" of
the Added file (which is copied from the original pre-branch
location). So the simple logic in the tree conflict resolver cannot
detect that D-A pair as a move (it is not smart enough to see that you
created test2 from test in the exact same revision). In theory, this
should be a supportable scenario, but it'll take some special handling
I think.

When I create branches, I usually do so purely in the repository, by
copying URL's (either from TortoiseSVN's repo browser, or by 'svn cp
URL1 URL2' -- keep in mind that the caret for SVN is a shortcut for
the repo-root-URL). That way the branch is a "clean" copy from
something else in the repository. I prefer to keep other changes
separate from the branch-creation, so either I commit them before or
after creating the branch.

The only exception I make to this is when creating tags for release,
where I commit a "version-number" change in some file together with
creating the tag. That's how the Subversion project creates its
release tags too, see for example
http://svn.apache.org/viewvc?view=revision=1914487

-- 
Johan

Re: [EXTERNAL] Re: Moved file resolution fails

[Sands, Daniel N. via users]

On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> [You don't often get email from nka...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
>  wrote:
> 
> > So lesson learned:  Always make a pristine copy of the trunk before
> > making ANY changes, so that there is a revision to fall back on
> > where
> > the two branches exactly match.
> 
> That's what tags are for!

I'd heard of tagging but wasn't sure how to do it since I'm not
responsible for the releases... but it looks like you tag by using the
copy command.  Even worse, the text under "complex tagging" shows
copying your working directory to a new repo, which is what breaks the
file move/rename detection.

On a further note, my real repo has 260 moves due to source tree
restructuring.  There were 290 deletions.  The current move detection
algorithm is an O(n^2) search to find all moves, where it ends up
querying the SVN server 260*290 times for merge info, per file
conflict.  Perhaps it would be a good cost savings to cache the merge
info for each file during the search, so that there are O(n) trips to
the server and everything else is resolved locally?

Re: Moved file resolution fails

[Nico Kadel-Garcia]

On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
 wrote:

> So lesson learned:  Always make a pristine copy of the trunk before
> making ANY changes, so that there is a revision to fall back on where
> the two branches exactly match.

That's what tags are for!

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> 
Okay, I finally figured out how to trip up SVN:




> > I built my own experiment which I'll try to reconstruct here:
> > mkdir test
> > mkdir test/foo
> > mkdir test/foo/bar
> > mkdir test/baz
> > echo "a" > test/foo/bar/example.c
> > svn import test svn+ssh://theserver/var/svn/playground/test
> > rm -rf test
> > svn co svn+ssh://theserver/var/svn/playground/test
> > cd test

Now I did something that SVN apparently doesn't like:

svn mv foo/bar/example.c baz
svn cp . ^/playground/test2

Problem:  This prevents SVN's mergeinfo search since on merge it looks
for the info on foo/bar/example.c at its previous revision in test2. 
The test2 repository itself does not exist in the previous revision,
let alone any file in it.  So, for example, we continue:


> > svn revert -R .
> > echo "b" > foo/bar/example.c
> > svn commit
> > cd ..
svn co svn+ssh://theserver/var/svn/playground/test2
cd test2
> > svn merge ^/playground/test 


And now here come the unresolvable conflicts!

So lesson learned:  Always make a pristine copy of the trunk before
making ANY changes, so that there is a revision to fall back on where
the two branches exactly match.

Re: Moved file resolution fails

[Sands, Daniel N. via users]

On Tue, 2024-02-13 at 16:50 -0700, Daniel Sands wrote:
> > Sorry for the late response, but I lack the time to dig deeper. It
> > should work as in the example (test) that Stanimir Stamenkov posted
> > earlier in this thread.
> > 
> I don't fully follow that Derby example, but it does not look like
> the
> same thing.
> 
> I built my own experiment which I'll try to reconstruct here:
> 
> mkdir test
> mkdir test/foo
> mkdir test/foo/bar
> mkdir test/baz
> echo "a" > test/foo/bar/example.c
> svn import test svn+ssh://theserver/var/svn/playground/test
> rm -rf test
> svn co svn+ssh://theserver/var/svn/playground/test
> cd test
> svn cp . ^/playground/test2
> cd ..
> svn co svn+ssh://theserver/var/svn/playground/test2
> cd test
> echo "b" > foo/bar/example.c
> svn commit
> cd ../test2
> svn merge ^/playground/test .
> 
> 
Further investigation from debugging the svn client 1.14:  In the above
test branch, the conflict resolution goes through the function
find_revision_for_suspected_deletion and returns the revision where it
happened.  But in my problem branch, this function cannot find the
revision where the file was deleted.  This makes no sense to me, as it
was in the previous checkin.

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> Sorry for the late response, but I lack the time to dig deeper. It
> should work as in the example (test) that Stanimir Stamenkov posted
> earlier in this thread.
>
> Is your case the same as in the DERBY issue that Stanimir referenced
> [1]? Maybe you can narrow it down to a test with a repository from
> scratch, or narrow down to a specific step that might have confused
> the tree conflict resolver?
>
> Perhaps someone else on this list has some more ideas / can zoom in
> on
> the case in [1]?
>
> [1]
> https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17582731=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17582731
>

I don't fully follow that Derby example, but it does not look like the
same thing.

I built my own experiment which I'll try to reconstruct here:

mkdir test
mkdir test/foo
mkdir test/foo/bar
mkdir test/baz
echo "a" > test/foo/bar/example.c
svn import test svn+ssh://theserver/var/svn/playground/test
rm -rf test
svn co svn+ssh://theserver/var/svn/playground/test
cd test
svn cp . ^/playground/test2
cd ..
svn co svn+ssh://theserver/var/svn/playground/test2
cd test
echo "b" > foo/bar/example.c
svn commit
cd ../test2
svn merge ^/playground/test .

This causes some interesting back-and-forth as it first records the
tree conflict on foo/bar, then starts checking for tree conflicts.
Looks like 1.14 did at least improve on the results though.

1.10 searched back through the revisions and finally gave up with:
Tree conflict on 'foo/bar':
Changes destined for a directory arrived via the following revisions
during merge of
'^/playground/test/foo/bar:34563-34565':
 r34562 by dnsands, r34565 by dnsands
No such file or directory was found in the merge target working copy.
The directory was moved to '^/playground/test2/baz/bar' in r34564 by
dnsands.

Subversion is not smart enough to resolve this tree conflict
automatically!
See 'svn help resolve' for more information.

1.14 was able to fully resolve the conflict by itself:
Changes destined for a directory arrived via the following revisions
during merge of
'^/playground/test/foo/bar:34563-34565':
 r34562 by dnsands, r34565 by dnsands
No such file or directory was found in the merge target working copy.
The directory was moved to '^/playground/test2/baz/bar' in r34564 by
dnsands.
Applying recommended resolution 'Apply to move destination':
--- Merging differences between repository URLs into 'baz/bar':
Ubaz/bar/example.c
Tree conflict at 'foo/bar' marked as resolved.
Summary of conflicts:
  Tree conflicts: 0 remaining (and 1 already resolved)

That's nice for this example at least, but it would seem that my actual
case was a bit more complex, as even 1.14 was unable to find the
original file.  I'll have to see if I can reproduce that in a simpler
case.  What I know is that it was unable to find a common ancestor
where the incoming merge destination existed.

Re: Moved file resolution fails

[Johan Corveleyn]

On Mon, Feb 5, 2024 at 8:57 PM Sands, Daniel N. via users
 wrote:
> > 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]).
>
> Yeah I'm using RHEL8 which currently supports 1.10.  I also compiled
> the latest version of 1.14 to see if it had any improvement.
> Unfortunately they all fail the same way in attempting to resolve file
> moves.

Sorry for the late response, but I lack the time to dig deeper. It
should work as in the example (test) that Stanimir Stamenkov posted
earlier in this thread.

Is your case the same as in the DERBY issue that Stanimir referenced
[1]? Maybe you can narrow it down to a test with a repository from
scratch, or narrow down to a specific step that might have confused
the tree conflict resolver?

Perhaps someone else on this list has some more ideas / can zoom in on
the case in [1]?

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

-- 
Johan

Re: Moved file resolution fails

[Sands, Daniel N. via users]

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

Yeah I'm using RHEL8 which currently supports 1.10.  I also compiled
the latest version of 1.14 to see if it had any improvement. 
Unfortunately they all fail the same way in attempting to resolve file
moves.

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

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, /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

[Daniel Sahlberg]

fre 2 feb. 2024 kl. 06:52 skrev Sands, Daniel N. via users <
users@subversion.apache.org>:

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


Which version are you using on the client side? Can you show the output of
svn —version?

Kind regards
Daniel Sahlberg

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

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> 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

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.

Re: Moved file resolution fails

[Stanimir Stamenkov via users]

Tue, 30 Jan 2024, /Sands, Daniel N./:

So far I have not found a use case where moved file resolution in 1.8+ 
works as advertised on 1.7 servers.  But more specifically, I have the 
following case:


The trunk has a directory,
/foo/bar

In my local branch, I have relocated bar to
/baz/bar

Meanwhile, in the trunk, file /foo/bar/example.c got updated.  My local 
branch has been checked out from the 1.7 server so it no longer knows 
specifically about file moves.  When I merge the latest changes from the 
trunk, it creates a tree conflict on /foo/bar. It has completely lost 
the notion that there is a file within /foo/bar that was edited.


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.


 The 
conflict data only knows that /foo/bar doesn't exist anymore.  My only 
option for resolution is to accept working – the search for where 
/foo/bar went also fails. And now the incoming edit to example.c is 
completely lost, and I wouldn't even know it existed until I did an svn 
diff on each revision that got merged in.


If I remember correctly, this had only worked the way you expect – 
automatic content merge into the moved file, pre-Subversion 1.6 when 
tree conflicts have been introduced.  I have never been a fan of this 
change and the complication to the svn merge it adds.


The way you generally resolve tree conflicts is with an extra merge (but 
could also be a delete) command per file/tree conflict:


svg merge ^/foo/bar baz/bar

Then you mark the conflicting files (command per path) as resolved:

svn resolve baz/bar --accept working

and finally commit, if you're satisfied with the state.

--
Stanimir

Moved file resolution fails

[Sands, Daniel N. via users]

So far I have not found a use case where moved file resolution in 1.8+ works as 
advertised on 1.7 servers.  But more specifically, I have the following case:

The trunk has a directory,
/foo/bar

In my local branch, I have relocated bar to
/baz/bar

Meanwhile, in the trunk, file /foo/bar/example.c got updated.  My local branch 
has been checked out from the 1.7 server so it no longer knows specifically 
about file moves.  When I merge the latest changes from the trunk, it creates a 
tree conflict on /foo/bar.  It has completely lost the notion that there is a 
file within /foo/bar that was edited.  The conflict data only knows that 
/foo/bar doesn't exist anymore.  My only option for resolution is to accept 
working – the search for where /foo/bar went also fails.  And now the incoming 
edit to example.c is completely lost, and I wouldn't even know it existed until 
I did an svn diff on each revision that got merged in.

So in summary, conflict resolution cannot find the new location for the 'bar' 
directory, and it completely forgot that there was an incoming file edit within 
that directory.

Is this a missed case in the resolution heuristic?  Or is there something I 
missed?