Good morning Julian,
julianf...@apache.org wrote on Thu, 15 Mar 2018 20:43 +:
> Author: julianfoad
> Date: Thu Mar 15 20:43:30 2018
> New Revision: 1826864
>
> URL: http://svn.apache.org/viewvc?rev=1826864&view=rev
> Log:
> Viewspec: Add an experimental viewspec output command.
>
> This repo
phi...@apache.org wrote on Fri, 16 Mar 2018 01:39 +:
> Author: philip
> Date: Fri Mar 16 01:39:21 2018
> New Revision: 1826912
>
> URL: http://svn.apache.org/viewvc?rev=1826912&view=rev
> Log:
> * publish/mailing-list.html: Add new Apache links, remove broken mbox links.
>
> Modified:
> s
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
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 initial dumb viewspec
ou
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
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
utf8
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 file://`pwd`/repo/subversion/trunk ^/subversion/
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 el
On Wed, Mar 14, 2018 at 1:07 PM, Johan Corveleyn wrote:
> On Wed, Mar 14, 2018 at 1:06 PM, Johan Corveleyn wrote:
>> On Wed, Mar 14, 2018 at 12:22 PM, Branko Čibej wrote:
>>> On 14.03.2018 08:58, Julian Foad wrote:
>> ...
If anyone's willing to write a brief list of the changes since RC1, t
20 matches
Mail list logo
