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

Re: [DISCUSS] delete ra_neon

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 17 May 2012 03:21:47 -0400

On Wed, May 16, 2012 at 10:40 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 05/16/2012 10:13 AM, Greg Stein wrote:
>> On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> but:  How hard would it be to temporarily maintain two commit paths -- one
>>> that drives an Ev2 editor, and one that drives Ev1?  The call to
>>> svn_ra_get_commit_editorN() would return NOT_IMPLEMENTED from ra_neon (and
>>> ra_svn), and the client would detect this and call the previous
>>> Ev1-returning API and drive it accordingly?
>> Certainly doable. And then it leads to a new question: "how long do we
>> support these two commit drive code paths?", and it does not provide
>> an answer for ra_neon itself.
> We support two commit drive code paths until we need only support one.  (Duh?)

My point was to get rid of double code paths (ie. ra_serf and
ra_neon). And then you suggest a different dual path :-P ... of
course, it is a smaller maintenance footprint, so maybe it is still

> The question of whether to drop ra_neon is independent, in my mind, from
> this Ev2 matter.  Subversion must continue to work for our users.  That's
> not optional.

Definitely othogonal. Agreed. It is simply that the Ev2 work is making
the pain more acute.

> Ev2 is optional, infinitely delay-able.  Clearly, we want to move forward
> with Ev2 because of the additional benefit we believe it will bring to our
> users, so we've an incentive to remove barriers to that progress.  One such
> barrier could be "the cost of coding Ev2 support in ra_neon".  I kinda doubt
> it, but I'm willing to defer to those closer to the problem.

It's a SMOP. Sure, we can do Ev2 for ra_neon, or we could rely on the
shims. We might be able to find a blended approach such as a custom
shim that avoids the big issues, yet defers to the Ev1 commit editor
for the bulk of the work.

> At any rate, I suggest we make the call on ra_neon/ra_serf first.  Now.

Right. Thus my intent to start the discussion. Give it a few days or
so, see where it goes.

> If ra_serf covers the feature set of ra_neon, I'm fine with ditching
> ra_neon.

I believe it does.

Philip has raised the traffic size issue (or alternatively CPU to
enable mod_deflate); dunno whether he would characterize that as a
blocker, however. There is also an issue (3981) that seems to cause
hangs over https; not sure how prevalent that is, or if we can narrow
it down. I suspect the traffic size can be corrected for checkouts by
switch to Depth:1 PROPFIND requests. The hang that philip observes
seems repeatable, so fixable.

> There may come a day when I (or Ivan, or someone ...) re-adds the
> non-skelta mode back to our DAV layer as an option if good technical reason
> to do so is established, and should that day come, I trust that no one will
> stand in the way of that for non-technical reasons.

I remain dubious, but that's just another discussion about tradeoffs.
I dunno that it has specific bearing right now.


So back to the original discussion, I see two points:

1) conceptually, is anybody opposed to deleting ra_neon?
2) what blockers to this path exist?

And related: is there any support for keeping ra_neon? I haven't seen
any calls for that on this thread, other than to mention the

Received on 2012-05-17 09:22:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.