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 <br...@apache.org > <mailto:br...@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 > >
