On Fri, Apr 6, 2012 at 14:24, Hyrum K Wright <hyrum.wright_at_wandisco.com> wrote:
> On Fri, Apr 6, 2012 at 1:10 PM, Greg Stein <gstein_at_gmail.com> wrote:
>>
>> On Apr 6, 2012 2:05 PM, "Hyrum K Wright" <hyrum.wright_at_wandisco.com> wrote:
>>>
>>> In case folks haven't been following commits@, there's been a bit of
>>> work on the ev2-export branch on implementing Ev2 drivers for commits.
>>> While we're not quite ready for it yet, at some point we'll need to
>>> start thinking about how to marshall Ev2 drives over the wire to
>>> waiting servers. As this design work is largely orthogonal to the
>>> current implementation efforts, and my familiarity with our existing
>>> protocols is pretty weak, I'd invite other folks to start thinking
>>> about these issues and discussing them here.
>>
>> Already ahead of you :-)
>>
>> I was going to suggest a new RA API rather than rev'ing get_commit_editor.
>> By going that route, the coding can occur on trunk, and we migrate as
>> appropriate, leaving the delta editor in place.
>
> Yep, that's the same conclusion I reached a few days ago. ;)
I'm thinking of a signature kind of like this:
svn_ra_begin_commit(
svn_editor_t **editor,
const svn_editor_plan_t *plan,
apr_hash_t *revprops,
svn_commit_callback2_t callback,
void *callback_baton,
apr_hash_t *lock_tokens,
svn_boolean_t keep_locks,
result_pool, scratch_pool)
It looks very similar to the get_commit_editor() function, except for
taking a plan. That will be delivered to the server, and if it comes
back "ok", then you get an editor back which you then drive (much like
today). The plan is used for out-of-dateness checks and authorization
(ie. "okay to proceed"), and to avoid sending content to the server
when the checksum matches (we just close the CONTENTS stream rather
than deltify/deliver to the server).
With this approach, we don't need to worry about Ev2 random order or
holding back content streams.
The plan is a new opaque structure that holds delete/modify/add
markers for relpaths. It doesn't need copy/move information, but just
what will be done at the relpaths. The server does authz, and makes
sure the revision is proper for deletes and modifications, and that an
add/add conflict has not occurred. Children of an added directory do
not need to be stored in the plan. Result checksums are stored for
each modified/added file.
We may find some other bits to store, but that's the basics. It is
constructed by the commit drivers.
If an RA layer has not (yet) been coded to deal with the commit plan,
then some common backwards-compat code can do the right mix of
open_file/open_dir/add_dir/delete/etc that we normally use at this
part of a commit. (this may require storing copyfrom information to
pass to add_file/add_dir). Point here is that we shouldn't need any
shims; just this interop code for third-party RA layers, or for our
layers which have not been updated.
>
>> This would be the new "commit plan, followed by drive" design we discussed.
>>
>> The new RA entrypoint(s) could even have a default implementation in ra/
>> that would use the original delta editor. Thus, we don't even have to
>> implement the new interface for all layers.
>
> This is a possibility. The current commit_editor4() on the ev2-export
> branch wraps the Ev1 implementation using the shims.
Well... I'm not talking about using the shims, in favor of
compatibility code that is attuned to the commit process. And the fact
that we're already got a bunch of file/dir batons from the planning
step.
That's my thinking so far...
Cheers,
-g
Received on 2012-04-06 23:11:26 CEST