[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal: new fsfs.conf properties

From: Paul Hammant <paul_at_hammant.org>
Date: Thu, 13 Jul 2017 14:24:45 -0400

Is Mod_Dav_Svn a TSR* thing? Or wholly re-entered for each request that
would require it?

* https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program

On Thu, Jul 13, 2017 at 2:11 PM, Branko Čibej <brane_at_apache.org> wrote:

> On 13.07.2017 16:07, Daniel Shahaf wrote:
> > On Thu, Jul 13, 2017 at 06:34:17AM -0400, Paul Hammant wrote:
> >> Or am I really wanting Svn's backend compression and deltification to be
> >> out of band ?
> >>
> >> 1. compression-strategy = defer-to-idle-time-even-if-days-later
> >> 2. deltification-strategy = defer-to-idle-time-even-if-days-later
> > That's indeed conceivable: compression/deltification could, in principle,
> > be deferred to 'svnadmin pack' time, so a commit would create PLAIN reps
> > (or DELTA reps against whatever base the client happened to choose) and
> > a subsequent 'svnadmin pack' would convert them to skip-deltas DELTA
> reps.
> >
> > Wouldn't even require a format bump :-)
>
> I agree, I've been thinking for a long time that compression and/or
> deltification is a waste of time during commit. I'm not sure we'd really
> want to defer it to 'svnadmin pack'; but, e.g., spawning off a daemon
> process to post-process the commit might not be a completely silly idea.
> Especially as we're not exactly good at using up all available cores on
> the server.
>
> -- Brane
>
Received on 2017-07-13 20:24:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.