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

Re: svn commit: r1329015 - in /subversion/trunk/subversion: include/private/svn_ra_private.h libsvn_ra/editor.c libsvn_ra/ra_loader.c libsvn_ra/ra_loader.h

From: Greg Stein <gstein_at_gmail.com>
Date: Sun, 22 Apr 2012 21:11:07 -0400

On Sun, Apr 22, 2012 at 20:59, <gstein_at_apache.org> wrote:
> Author: gstein
> Date: Mon Apr 23 00:59:46 2012
> New Revision: 1329015
>
> URL: http://svn.apache.org/viewvc?rev=1329015&view=rev
> Log:
> Provide a first pass at (private) APIs to fetch an EV2-based commit
> editor from the RA layers. Some of this is based on Hyrum's work on
> the ev2-exports branch (see editor.c below).
>
> If an RA layer supports this new API, then it is used. Otherwise, an
> Ev2 shim is inserted over its Ev1-based commit editor and returned.

The concept here is that we'll provide *two* commit editors out of the
RA layers. The existing Ev1-based editor, and the new Ev2-based
editor. Both are provided during the transition period. The Ev1 API
will need to stick around for compatibility purposes, so I don't think
we're really losing much by creating a second (Ev2-based) path. At
some point in the future, we can simply deprecate the Ev1 version (as
if we had moved from get_commit_editor3() to get_commit_editor4()).

This is a different strategy from Hyrum's branch, where
get_commit_editor3() has been deprecated in favor of an Ev2 version
(ie. only one "valid" path).

For now, the Ev2-based APIs are all private. Once we're comfortable
with them, then we can make them public. Third parties can continue to
use the Ev1-based commit editor.

The Ev2-based commit editor can be built incrementally. For example,
it could support *just* add_directory() and then we switch the 'svn
mkdir URL' code over to use the Ev2 interface. Even if that gets run
against an "old" RA layer and an Ev2/Ev2 shim is interposed, the shim
won't create much of a problem since you're only operating on one (or
a few) target paths. (the shims buffer all modified paths, basically,
so we want to avoid them in "unbounded" commit sequences)

Since a shim is used when needed, we can also implement the Ev2 APIs
on one RA layer at a time. We don't have to code them all at once.
Only when we want to avoid the Ev2/Ev1 shim and its overhead.

Lastly: note that these are not bounded by any conditional
compilation. This is unrelated to the ENABLE_EV2_SHIMS code, which
interposes an Ev1/Ev2 and an Ev2/Ev1 shim around each delta (Ev1)
editor created. This is true Ev2 work, only pending code that will
make use of it.

Cheers,
-g
Received on 2012-04-23 03:11:42 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.