On Wed, Feb 1, 2012 at 02:28, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Greg Stein wrote on Tue, Jan 31, 2012 at 23:08:17 -0500:
>> The "plan" is some new XML report-like document, posted to the "me"
> We've defined HTTPv2 such that the body of POSTs is skels, not XML.
Ah. Right. I was thinking of the report processing. The skel approach
is much nicer. Thanks for the reminder!
> 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.
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
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.
Received on 2012-02-01 09:08:38 CET