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
better.
> 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
possibility.
Thanks,
-g
Received on 2012-05-17 09:22:22 CEST