Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin writes: > I've committed and nominated for 1.10. However I have found another > caching problem: > > https://issues.apache.org/jira/browse/SVN-4727 > > Loading my copy of the original Collab Subversion repository (40515 > revisions) fails when the cache

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin writes: > With a small cache the load completes and verification works, but > verfication fails with a large cache: > > * Error verifying revision 11826. > svnadmin: E160004: Corrupt node-revision '5-385.0.r8127/80' > svnadmin: E160004: Reading one svndiff

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Branko Čibej writes: > On 15.03.2018 20:38, Philip Martin wrote: >> Philip Martin writes: >> >>> I think the raw >>> window cache may have to be modified to include the svndiff version. >> Experimental patch: > > Looks approximately correct to me.

Re: [PATCH] Hackathon project: Dumping viewspec

Johan Corveleyn wrote: On Sun, Nov 26, 2017, Stefan wrote: On 25/11/2017, Stefan Sperling wrote: On Fri, Nov 24, 2017, Bert Huijben wrote: At the Aachen hackathon I promised to write some code to spit out the sparse definition of a working copy, or in other words some

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

On 15.03.2018 20:38, Philip Martin wrote: > Philip Martin writes: > >> I think the raw >> window cache may have to be modified to include the svndiff version. > Experimental patch: Looks approximately correct to me. Hard-coding version 1 would have been wrong before

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin writes: > I think the raw > window cache may have to be modified to include the svndiff version. Experimental patch: Index: subversion/libsvn_fs_fs/cached_data.c === ---

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Branko Čibej writes: > The svndiff version is embedded in the first 4 bytes of the window data > and should be parsed from there. When we store the data in the raw window cache the svndiff version isn't part of the stored data. When we subsequently retreive the data from the

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Julian Foad writes: > Philip Martin wrote: >> cached_data.c:parse_raw_window() where the svndiff version is hard-coded >> to 1 in the call to svn_txdelta_read_svndiff_window. Changing that to 2 >> allows the regression test to pass, the question is where should the >>

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin wrote: cached_data.c:parse_raw_window() where the svndiff version is hard-coded to 1 in the call to svn_txdelta_read_svndiff_window. Changing that to 2 allows the regression test to pass, the question is where should the correct value be obtained? The simple answer appears to be

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

On 15.03.2018 18:50, Philip Martin wrote: > Philip Martin writes: > >> Evgeny Kotkov writes: >> >>> Philip Martin writes: >>> That works as expected, but vary the cache size of the load process and it

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin writes: > Evgeny Kotkov writes: > >> Philip Martin writes: >> >>> That works as expected, but vary the cache size of the load process and >>> it fails. The load succeeds with -M64 and smaller but

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Evgeny Kotkov writes: > Philip Martin writes: > >> That works as expected, but vary the cache size of the load process and >> it fails. The load succeeds with -M64 and smaller but fails with -M65 >> and larger: > > [...] > > Maybe this

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin writes: > That works as expected, but vary the cache size of the load process and > it fails. The load succeeds with -M64 and smaller but fails with -M65 > and larger: [...] Maybe this behavior could be related to the cache size threshold in svnadmin

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin writes: > $ svnadmin dump -q repo | svnadmin load -q -M1000 repo2 > svnadmin: E140001: zlib (uncompress): corrupt data: Decompression of > svndiff data failed This is now issue https://issues.apache.org/jira/browse/SVN-4725 -- Philip

Re: New build requirements for 1.10?

I currently just use the internal builds for my binaries and don't see a reason to upgrade them separately. Utf8proc is only used in 'svn' at this time. I still build SQLite myself, but just passing the amalgamation works for others. I don't think there is even support to use external LZ4 and

svnadmin load error with 1.10 that seems to be fsfs cache related

Julian Foad writes: > Julian Foad wrote on 2018-02-28: >> I'm happy to announce the release of Apache Subversion 1.10.0-rc1. > > That was 2 weeks ago and we need an RC2. svnadmin create repo svn -mm mkdir file://`pwd`/repo/subversion svn -mm mkdir

Bumping the help text API [was: svn commit: r1826328]

Daniel Shahaf wrote: julianf...@apache.org wrote: [...] +/** The maximum number of paragraphs of help text a subcommand can have. */ Missing "@since New in 1.11" annotation. +#define SVN_OPT_MAX_PARAGRAPHS 50 Done. @@ -77,6 +80,37 @@ typedef svn_error_t *(svn_opt_subcommand /** One