[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 1 Feb 2012 03:07:56 -0500

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"
>> 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
Received on 2012-02-01 09:08:38 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.