Re: How to improve search performance for moved directories and files?

Guten Tag Daniel Shahaf,
am Montag, 24. Februar 2020 um 18:27 schrieben Sie:

> If the remote repository uses https://, you could set up mod_dav_svn on
> localhost in a proxy configuration. For svn:// the equivalent would be
> to set up an svnsync mirror and do «svn relocate»'s to and from it by
> hand.[...]

Thanks for the suggestions, but I can't expect my coworkers to do
that. Some of them would simply prefer discussing if to keep using
SVN at all in favour of ... we all know what. ;-)

I'm regularly getting the SVN-repos from the remote host using RSYNC
locally anyway. So while not as correct as using svnsync in theory, I
can simply do a 2 URL-merge using unrelated file-URIs with my local
backups of the repos. That at least saves me from the relocate. The
only thing I'm missing this way is merge tracking and merge recording.
At least the latter can can be done after merging using the remote
target again by telling the SVN-client to record the merge only. That
is fast enough as no conflicts are triggered at all.

Two additional questions:

1. Why does the number of revisions seem to matter that much?

This kind of merge conflict seems to become slower and slower as the
number of revisions increases, even if all of those commits belong to
totally unrelated branches. Additionally, the commits moving the
directories and triggering the conflicts are not that far in the
past, only very few hundreds of commits.

Something like the following: 100 auto-commits in branchA, very few
commits moving directories in branchB, 100 auto-commits in branchA
again. I would have expected the SVN-client focussing on branchB and
finding the possible move targets in that branch pretty early.

2. Really no other handbrake somewhere?

When doing the merge locally, I have a very high CPU-usage, but very
little I/O, like constantly something around 40 Kbit/s. That doesn't
matter locally especially in case using a SSD of course, but does
remotely because of the additional latencies I guess.

So, is that simply how things work? Lots of small reads in those
cases introducing lots of latency slowing things down heavily? And
that can't be easily optimized further by e.g. any setting of the
SVN-client?

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening_at_AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow