On 17.03.2018 13:57, Philip Martin wrote:
> Julian Foad writes:
>
>> But does that mean this code isn't being tested by any of our manual
>> or buildbot testing in the last 6 months?
> Yes, I think so.
>
> For svnserve the code only gets enabled when svnserve has block-read
> enabled and svnservea
Julian Foad writes:
> But does that mean this code isn't being tested by any of our manual
> or buildbot testing in the last 6 months?
Yes, I think so.
For svnserve the code only gets enabled when svnserve has block-read
enabled and svnserveautocheck doesn't do that. By invoking svnserve
manua
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 is large:
>
> svnadmin: E160
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 window read beyond the end
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. Hard-coding version 1 would have been
> wrong be
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 LZ4, too, since version 0 does
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
===
--- subversion/libsvn_fs_fs/cached_data.c (re
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 cache the svndiff v
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
>> correct value be obtained?
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
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 fails. The load succeeds with -M64 and smaller but fails with -M65
and larger:
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 fails with -M65
>>> and larger:
>>
>> [...]
>>
>> Maybe this behavior could be relat
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 behavior could be related to the cache size threshold in sv
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
that enables the block read f
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
15 matches
Mail list logo
