Re: Ev2, RA, Commit Process (was: Editor v2 - suggestions and queries)

Greg Stein wrote on Wed, Feb 01, 2012 at 03:07:56 -0500:
> On Wed, Feb 1, 2012 at 02:28, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Also, you didn't talk about ra_svn at all.  Presumably it's trivial
> > there (we can just extend the protocol to mirror the new APIs), but
> > explicitness won't hurt.
>
> I presume it should be pretty easy, but have no idea how the svn
> protocol does capability negotiation or gets extended.
>

There is support for server capabilities and client capabilities.
Extension options are:

    4. Extensibility
    ----------------

    This protocol may be extended in three ways, in decreasing order of
    desirability:

      * Items may be added to any tuple. An old implementation will
        ignore the extra items.

      * Named extensions may be expressed at connection initiation time
        by the client or server.

      * The protocol version may be bumped. Clients and servers can then
        choose to any range of protocol versions.

> IIRC, the delta editor interface simply gets marshaled over the wire.
> Maybe we just pass a plan-skel over the wire? Oh. Wait. svn protocol
> doesn't actually use skels, does it? Something similar, but entirely
> different if I remember right. (SIGH) ... I guess we can always embed

Yes. It doesn't use skels but another similar syntax with a slightly
different marshalling syntax.

> a serialized skel within svn's other-funky serialization format.
>
> Oh. And that is an interesting point. We need server-side processing
> of a commit plan. Maybe the plan code goes down into libsvn_subr so
> both sides can create/consume/process the plans. I suspect that
> server-side processing would go into libsvn_repos and use existing FS
> APIs to pass/fail a commit plan.
>
> Cheers,
> -g
Received on 2012-02-01 09:18:17 CET