On Wed, Feb 1, 2012 at 02:28, Daniel Shahaf <danie...@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" >> resource > > We've defined HTTPv2 such that the body of POSTs is skels, not XML. > (dav_svn__method_post())
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. Cheers, -g
