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