On 28.01.2011 05:27, Hyrum K Wright wrote:
On Wed, Jan 26, 2011 at 4: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 :)
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
Merge is done and everything got adapted
to support both server types equally. The new
caching code is active by default.
BTW, how / where do we document things like
the new mod_dav_svn module parameter?
-- Stefan^2.
