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

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 [email protected]. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
> > <[email protected]> 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.

> 
>