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

Re: Enhancement suggestion...

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 26 Mar 2009 15:02:04 +0100

On Thu, Mar 26, 2009 at 14:47, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Mar 26, 2009 at 9:35 AM, Greg Stein <gstein_at_gmail.com> wrote:
>...
>> I suspect we can have our v2 http protocol do the right operation.
>> Might need some FS changes, though: we'd need to copy a node, but not
>> leave copy information. For http v1, we'd probably just have to send
>> it multiple times like today.
>
> With the new rep-sharing feature we in theory do not store the file
> multiple times in the repository.  So what if a client were to tell
> the server what it was going to send, along with the checksums, and
> the server were to reply, OK, send me this one, but not that one.  I
> already have it?

I thought about the rep-sharing and that we wouldn't store it multiple
times. But I hadn't thought about a pre-flighting test. Good one.

We could pass a list of checksums in the initial POST to the server.
In its reply, it could tell us which checksums it already has (the
list of "have" will probably be shorter than the list of "need").

The client will still have to tell the server more about the node:
add? copy? properties? etc. So maybe we do that with PROPPATCH or a
POST.

> I recall you were thinking of something similar in WC-NG for
> checkout/update etc.  If the server is going to give the file it
> already has in its cache, it could skip downloading it.

Right. The checksums come back to the client as properties in a
PROPFIND. We'd simply skip the corresponding GET operation.

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1430423
Received on 2009-03-26 15:02:30 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.