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

Re: Merging /branches/integrate-cache-membuffer to /trunk

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Thu, 27 Jan 2011 22:27:26 -0600

On Wed, Jan 26, 2011 at 4: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 :)

It won't get tested very much if it's disabled (made "opt-in")
directly after being merged back to trunk. :)

I'd say merge to trunk, leave it enabled, and *if* we see some big
problems, we can throw the kill switch prior to shipping. It's trunk,
for goodness' sake, it doesn't have to be pristine.

My $.02,
-Hyrum
Received on 2011-01-28 05:28:04 CET

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.