Big thanks to both Sean and Guido for their help in tracking down the issue.
It seems indeed to be a bug in the Subversion code. I've added
d...@subversion.apache.org for further debugging - this goes out of scope of
the users list.
I believe several threads are accessing the same "translator"
si
Den tis 7 jan. 2025 kl 22:08 skrev Bo Berglund :
>
> This is how the execution went (long lines are wrapped by my newsreader):
>
> H:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize
> --sync-username syncuser https://svn.mydomain.com/svn/pc
> https://agiengineering/svn/pc
>
> Fail
On Tue, 07 Jan 2025 22:08:33 +0100, Bo Berglund wrote:
>In the batch file the command is created at the start and then used for all
>repos going down the file. Here is how it is defined (again wrapped lines):
>
>rem If a repository is not synced due to a lock problem, then use --steal-lock
>in a
On Tue, 7 Jan 2025 04:22:43 -0600, Ryan Carsten Schmidt
wrote:
>On Jan 7, 2025, at 03:48, Bo Berglund wrote:
>>
>> It seems like the sync was not really done for this repo for a long time even
>> though the nightly sync operation actually was working for all the other
>> repos
>> where the mirr
On 7 Jan 2025, at 2:07, Guido Jäkel wrote:
> I'm no developer, but Google probably tell me to add the right flags:
Yes, -fsanitize=thread is the main flag. You should also build in debug so that
you get filenames and line numbers.
Are you saying svn's own test suite does not pass under Thread S
On Tue, Jan 7, 2025 at 10:48 AM Bo Berglund wrote:
...
> I have also checked the commit emails for this repo and those show another set
> of commits done for revs 4519 to 4528 between 2024-08-14-2024-12-01, which is
> where the mirror should be now. But isn't
>
>
> Command svn info on the *mai
On Jan 7, 2025, at 03:48, Bo Berglund wrote:
>
> It seems like the sync was not really done for this repo for a long time even
> though the nightly sync operation actually was working for all the other repos
> where the mirror contains commits done up to the server crash...
Indeed!
> And it is
Dear Sean,
I'm no developer, but Google probably tell me to add the right flags:
root@testsub0
/var/tmp/portage/dev-vcs/subversion-1.14.5/work/subversion-1.14.5/testcase #
diff Makefile{.20250107-073455,} -u
--- Makefile.20250107-0734552025-01-07 07:34:55.0 +0100
+++ Mak
On Sun, 29 Dec 2024 00:49:21 +0100, Bo Berglund wrote:
>Since I did not succeed in getting this to work with svnrload and a
>StackOverflow search suggested I should use svnadmin instead:
>
>I reverted to svnadmin and look what happened:
>
>svnadmin load E:\SVNREPOS\cmpcpy < dump_cmp
><<< Started
