On Thu, Jan 27, 2011 at 11:58 PM, Stefan Fuhrmann <eq...@web.de> wrote: > On 27.01.2011 01:56, Johan Corveleyn wrote: >> >> On Wed, Jan 26, 2011 at 11:42 PM, Stefan Sperling<s...@elego.de> wrote: >>> >>> On Wed, Jan 26, 2011 at 11:25:59PM +0100, Stefan Fuhrmann wrote: >>>> >>>> Hi @all, >>>> >>>> I'm planning to merge said branch Monday 7th. >>>> Speak now or forever hold your peace. >>>> >>>> Rationale: >>>> >>>> I've been testing / using that code for a while now >>>> and am reasonably confident that it works. And it >>>> is not exactly rocket science, either. >>>> >>>> Because a large portion of my other performance >>>> work builds upon that low-latency caching feature, >>>> it would really like to see it being merged. Directly >>>> after the merge, I will make the feature strictly opt-in >>>> instead of defaulting to a 16 or 64 MB cache. >>> >>> I'd say merging to trunk is perfectly fine if you're confident that >>> there aren't any roadblock issues and it's not enabled by default anyway. >>> We've released optional new features in the past (e.g. libsvn_serf). >>> It's much more likely to get tested this way :) >> >> Would there be a way to opt-in with a mod_dav_svn server? IIRC, you >> have added some configuration options for svnserve, but not yet a way >> to configure it with an apache server (unless I missed something). >> Maybe you or someone else can add the necessary configuration >> directives or anything else that needs to be done for this ... > > My intend is to add Apache config file support. > We use mod_dav_svn only in my company, so > I have a vested interest in supporting that setup ...
Ah, great! >> >> I wouldn't want to miss out on the caching benefits, but for now I >> wasn't too worried because I was content with a default of 64 MB. > > It's more about defaulting to "no extra risk". Yes, I agree that's the best approach. Cheers, -- Johan
