Greg Stein wrote on Wed, Feb 01, 2012 at 03:07:56 -0500:
> On Wed, Feb 1, 2012 at 02:28, Daniel Shahaf <danie...@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
