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 > > <us...@subversion.apache.org> 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
