On Thu, Jan 27, 2011 at 11:58 PM, Stefan Fuhrmann <eqfox_at_web.de> wrote:
> On 27.01.2011 01:56, Johan Corveleyn wrote:
>>
>> On Wed, Jan 26, 2011 at 11:42 PM, Stefan Sperling<stsp_at_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
Received on 2011-01-28 00:08:35 CET