On Tue, Sep 30, 2008 at 5:20 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> OK, I think I'm game for this plan. I can start revising the
> designdoc in this direction:
>
> 1. We can design a 'core' protocol which is basically a direct mapping
> of RA calls to (proprietary) single-turnaround GET and POST requests.
> No mess, no fuss. Lean and mean.
Sounds good.
> 2. We can also throw in a secondary protocol which is pure WebDAV (no
> DeltaV), so that drives are still mountable via {GET, PUT, PROPFIND,
> PROPPATCH, COPY, MOVE, MKCOL, LOCK, UNLOCK}; we'd design the URI
> space to map *sanely* to svn objects, and make sure that immutable
> objects are explicitly flagged as cacheable. The URI spaces will be
> publically advertised as well. This would preserve autoversioning, as
> well as the built-in web-browsing feature.
Yup. Basically, just concentrating on what an arbitrary DAV client
will use... *actual* Subversion operations use the gunk from (1).
> There's still an open question in my mind as to whether an 'svn
> checkout' would be single proprietary GET request and massive response
> (as RA models it), or whether we could use a hybrid of the core & dav
> protocols (GET a skelta, then GET each individual file via
> pipelining.) We can work that out.
The latter. Reason: the client might already have all of the files
stashed away in its new checksum-keyed datastore of pristine files!
:-D (aka wc-ng)
Ideally, the server would respond with: "fetch <these> contents, and
here's their checksum values". The client can fetch or not, based on
whether it already has the pristine file. The individual fetches can
be pipelined (we *have* identified that as similar-perf to
mother-REPORT, *and* they're cacheable this way).
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 02:26:24 CEST