On Sun, Apr 22, 2012 at 8:11 PM, Greg Stein <gstein_at_gmail.com> wrote:
> 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)
I added an Ev2 capability to svn_ra.h on the ev2-export branch, which
we could use to check the ability of the client and/or server to
receiver Ev2-encoded deltas. Feel free to poach the one-line patch.
> 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.
Thanks for putting our discussion from last week in writing. The goal
here (for folks who aren't aware) is to get as much of the ev2-export
branch on branch relatively soon, with all the attendant benefits.
The trick in doing so is making sure that performance isn't negatively
impacted by having the shims be the default path through the editor.
Even though the above technique applies primarily to the commit
editor, I think the dual editor approach will work just as well for
update editors and the like, but that work is a bit farther out.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-23 14:06:52 CEST