[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 16 May 2012 10:40:59 -0400

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?)

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.

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.

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

If the call is "keep 'em both", then we do so, and we stop subconsciously
granting first-class citizenship to one or the other of our DAV RA modules.

If the call is "drop ra_neon", then we do so. Any features ra_serf lacks
that ra_neon offers (and which Subversion uses) become hard blockers to
Subversion 1.8.

If the call is "drop ra_serf", then we do so. Any features ra_neon lacks
that ra_serf offers (and which Subversion uses) become hard blockers to
Subversion 1.8.

The Ev2 stuff will be managed in accordance with the preexisting policies of
this community: trunk is stable, period. If we keep ra_neon, then Hyrum
must ensure that his Ev2 stuff continues to function with all RA layers
before it lands on trunk (through shims, or a dual commit drive approach, or
whatever). Let's not overcomplicate this.

If ra_serf covers the feature set of ra_neon, I'm fine with ditching
ra_neon. 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. That's about the only
semi-contentious thing I can recall in terms of the general approach that
ra_serf takes. Cool?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-05-16 16:41:34 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.