Why ra_serf should not (yet) be the default WebDAV RA implementation

Greg Stein wrote:
>> Another issue that has been raised in the past is that ra_serf does
>> not honor the depth-first editor API contract. That would need to be
>> fixed as part of becoming "official".
>
> Fixed or loosened. Personally, I think it should be loosened in order
> for us to get systemic performance increases. The depth-first
> requirements are too binding.

Loosen away, but you'll need to rev the editor API to do so. The editor has
promised a drive ordering for years, and while ra_serf has been in use for
years by a couple of folks, it's only been because certain of the editor
implementations *happened* to work with looser ordering, and at least one of
the others *I went out of my way* to change just to support ra_serf's
API-violating ordering. But the editors that ra_serf drives are not all
Subversion-internal -- our RA layer also drives many third-party editor
implementations, none of which are guaranteed to flawlessly work in an
order-agnostic editor drive situation.

Yesterday I was reading an exchange on this list in which one dev assumed
that ra_serf had a bug because ra_neon was passing regression tests and the
changed code wasn't RA-specific. The response was a very fair one: ra_serf
is clearly not experimental any more, so we need to stop assuming it's
garbage code that will get cleaned up later. But I'll admit that I was tad
put off by the invocation of the mantra "if you break the code, you fix the
code (or ask someone to help you fix it)" in that thread. I noticed this
API violation in ra_serf (issue #2932) *over a year ago* -- back when it
still was quite a bit more flaky and under active development -- and the
response was, essentially, "Meh". Even when others stepped up to describe
how a high degree of parallelism could still be maintained while honoring
the API, no effort was invested into making ra_serf do the right thing. And
while I recognize that dangers of thinking in terms of "my code / his code /
her code" (it's all "our code", right?), at that time there were only about
two folks for whom fixing ra_serf to do the right thing was *not* a
week-long research project. (I'm not convinced that that's not still the
case, even, but...)

Anyway, I see two roads we can take here:

   1. Rev the editor API to relax some of the ordering restrictions (and of
       course do so in a way that still makes for a sane API), and then
       tweak ra_serf to use the new editor API, or

   2. Fix ra_serf to honor the existing API.

Until one of these is done, my vote is a very strong -1 on disabling Neon as
the default WebDAV RA implementation. And, no, I am not signing up for
either task, because ra_serf doesn't scratch my itch (it more often causes
me grief, see below), the editor API works fine for my purposes, and my time
is required by other things.

Even if one of these is done, I'm not sure that I can relax that -1 simply
because of the sheer number of servers I've tried to use ra_serf against
where performance is absolutely abismal. Now, I'm confident that that's due
to server configurations, not problems with ra_serf, but it takes time to
roll out recommendations to Subversion repository hosts that pipelining be
permitted, and that is *not* the kind of recommendation you roll out *after*
jerking away the client-side implementation that works in all cases. We
should be telling Subversion server admins *today* that change is coming so
they have time to understand that message and respond to it before they have
1200 users trying to murder the server admin.

Having re-read (and re-edited) what I've written so far, I still can't
convince myself that the text won't be perceived by some as inflammatory.
That's not my intent. I have no love affair with ra_neon, and actually I
think the libserf/libsvn_ra_serf devs should be congratulated on the
relatively rapid development of this subsystem. It's just that as a person
who routinely writes code against Subversion's APIs, I take API promises and
compatibility seriously.

Meaning well (we swears),
-- C-Mike

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