[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: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 26 Mar 2009 09:47:39 -0400

On Thu, Mar 26, 2009 at 9:35 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Mar 26, 2009 at 14:22, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Thu, Mar 26, 2009 at 9:12 AM, Greg Stein <gstein_at_gmail.com> wrote:
>>
>>> Another approach in 1.6 that could work is to take advantage of
>>> knowing the protocol steps used. He could add and commit the
>>> lesson.exe to one directory. Then use "svn copy" to make copies of it
>>> to the other directories. At commit time, svn *should* tell the server
>>> to simply copy the file to the other directories. It shouldn't upload
>>> it again.
>>
>> This is the approach that I always use.  It works well for me.
>
> Yeah... but "user strategies" are always annoying, in favor of the
> tool just Doing The Right Thing.
>
> 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 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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1430268
Received on 2009-03-26 14:48:05 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.