On Wed, May 16, 2012 at 10:40 AM, C. Michael Pilato <[email protected]> wrote: > On 05/16/2012 10:13 AM, Greg Stein wrote: >> On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato <[email protected]> >> 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
