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 > > > <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. > > > > > > Hi, Any chance you can send your patch uncompressed, with an extension like ".patch.txt"? Thanks, Nathan
