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

Re: [VOTE]: Default http-client for 1.7 Serf or Neon

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 12 Aug 2011 10:26:58 -0400

On 08/12/2011 01:53 AM, Justin Erenkrantz wrote:
> On Fri, Aug 5, 2011 at 2:34 AM, Greg Stein <gstein_at_gmail.com> wrote:
>> Yet... we have seen bugs crop up over the past week in a number of
>> other areas (merge? mod_dav_svn? log? fs txns?). We accept those as
>> normal. They're fixed and backported. This is how we should be
>> operating on ra_serf, too. There is nothing special about it.
>
> +1.
>
> I feel that there are certain folks in the community that are
> constantly and actively changing the goal posts.

This is just argumentative nonsense, and you well know it, sir. The goal
posts are today where they've always been: to give Subversion users the
best "out-of-box" experience possible.

I'll remind you that we've been here before with FSFS and BDB. Nobody
demanded perfection of FSFS -- we made it the default when it was known to
have the occasional hiccup. But the benefits to admins of FSFS far
outweighed those rarely-observed costs. And nobody is demanding perfect of
Serf today. Those who have voiced a concern here merely wish not to take
steps *backwards* with the less-than-convincing promise of future forward
progress. So far, Serf has not demonstrably given anything to Subversion's
users except a greater likelihood of problems, fewer features, and slower
performance. This isn't my opinion here -- this is what testing and
experience has been and is revealing.

The *appearance* of moving goalposts comes from the fact that until a few
months ago when we started doing organized comparison testing of Serf vs.
Neon, many of us just sorta assumed that if the bugs in Serf went away, it
would surpass Neon in all dimensions. The interpretation of the goal
became, then, "make the bugs go away". Since then we've realized that it's
not merely the numerous segfaults, memory bloat, infinite loops -- the
"bugs" -- that are Serf's disadvantage vs. Neon. It's also the performance
characteristics and in some aspects even its very design. In my mind, there
are precisely two advantages of ra_serf vs. ra_neon: Serf has a more
palatable license, and ra_serf has more cleanly composed code. But as it
turns out, our users don't care a lick for either of those points.

The goal posts have not moved. But when the referee keeps giving 10-yard
penalties... yeah, the gap widens.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-08-12 16:27:41 CEST

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.