On 13.07.2017 20:24, Paul Hammant wrote:
> 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
>
Well since it doesn't run on DOS, it's not TSR :)
mod_dav_svn is a shared library loaded into the httpd process, it's not
a process itself. How long httpd's request handler process (or thread)
lives depends on a number of things, e.g., which MPM is in use and how
it's configured.
-- Brane
> On Thu, Jul 13, 2017 at 2:11 PM, Branko Čibej <brane_at_apache.org
> <mailto: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:29:03 CEST