subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: Ev2, RA, Commit Process (was: Editor v2 - suggestions and queries)
Date Wed, 01 Feb 2012 08:17:09 GMT
Greg Stein wrote on Wed, Feb 01, 2012 at 03:07:56 -0500:
> On Wed, Feb 1, 2012 at 02:28, Daniel Shahaf <> 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

      * 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

View raw message