Re: Proposal: new fsfs.conf properties

Evgeny Kotkov wrote: > I went ahead with implementing a slightly different solution that enables > delta streaming in ra_serf. (Currently, only for "svn import"; commits are > a bit more complicated, but shouldn't be too hard to switch to the new > approach, as all the necessary groundwork is in

Re: Checkpointing mock-up option 3 (backed by a local repo)

Nathan Hartman wrote: > Some thoughts (probably too many)... Not at all, this is fantastic, right where I want us to be, and very helpful. > I agree that 'init' and 'finish' should happen automatically. > [...] As for when the 'finish' should occur, [...] probably not > until the results have

Re: svn commit: r1803140 - in /subversion/trunk/subversion: include/svn_delta.h libsvn_delta/svndiff.c tests/libsvn_delta/random-test.c

Daniel Shahaf writes: > I did misunderstand the relation between the two streams, … > >> The internal buffer doesn't grow beyond the (header size + max window >> size in svndiff format), which is O(1). > > … but I still don't see why this statement is true. The stream

Re: svn commit: r1803140 - in /subversion/trunk/subversion: include/svn_delta.h libsvn_delta/svndiff.c tests/libsvn_delta/random-test.c

Evgeny Kotkov wrote on Thu, 27 Jul 2017 18:50 +0300: > Daniel Shahaf writes: > > >> +static svn_error_t * > >> +svndiff_stream_write_fn(void *baton, const char *data, apr_size_t *len) > >> +{ > >> + svndiff_stream_baton_t *b = baton; > >> + > >> +

Re: ra_serf: API and HTTP protocol changes to support delta streaming (was: Re: Proposal: new fsfs.conf properties)

Evgeny Kotkov wrote: > Thank you for this reminder, I have now taken this to a separate thread. Thanks, Evgeny, that all sounds clear now. FWIW, these changes sound fine to me, though my mind-space is far from that side of Subversion so that may not count for much. - Julian

Re: Checkpointing mock-up option 3 (backed by a local repo)

On Fri, Jul 28, 2017 at 8:19 AM, Julian Foad wrote: > Nathan Hartman wrote: > All considered, it feels to me like we have neither the collective will > nor the resources to take this in the direction of full local branching. > I can't commit myself to that. The present

RE: Data corruption bug in WC, apparently due to race condition?

> -Original Message- > From: Philip Martin [mailto:phi...@codematters.co.uk] > Sent: donderdag 27 juli 2017 19:57 > To: Karl Fogel > Cc: Subversion Dev > Subject: Re: Data corruption bug in WC, apparently due to race condition? > > Karl

ra_serf: API and HTTP protocol changes to support delta streaming (was: Re: Proposal: new fsfs.conf properties)

Julian Foad writes: > Hi Evgeny. Daniel Shahaf just noticed that r1803143 extended the > svn_delta_editor_t interface. So I took a look and see in the log > message that also: > >> This requires a minor tweak to the Subversion's HTTP protocol, and >> it's the reason why

FAQ entries #dumpload and (new) #fix-nonLF-log

I have extended the FAQ entry #dumpload [1], about the dump+load procedure, with some caveats and details on the technique to dump+load a large repository with minimal downtime. This is based on a users@ mail from last year [2] (I had been meaning to convert this into a FAQ since then, but only