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

Re: svn commit: r25992 - trunk/notes

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-08-08 21:17:45 CEST

Ben Collins-Sussman wrote:
> On 8/8/07, David Glasser <glasser@davidglasser.net> wrote:
>> On 8/8/07, sussman@tigris.org <sussman@tigris.org> wrote:
>>> + When driving the working copy update-editor, have the server send
>>> + copyfrom-args in add_file() and add_dir(). The server doesn't send
>>> + any txdeltas in this case.
>> To clarify, what you mean here is "Instead of sending txdeltas based
>> on the empty file, the server sends txdeltas based on the copy source
>> (and may send no txdeltas if it is an identical copy).", right?
>>
>
> Thanks for reading this.
>
> Why would the server ever send add_file(copyfrom=...) and *then* a
> txdelta against that? Clients do that, sure, since people do 'svn cp
> foo bar', and then make extra changes. But the server? There's no
> such thing as "extra edits" coming from a repository. (Or am I on
> crack?)

If I am able to transmit copy + mod to the server as part of a commit, why
shouldn't my peer get copy + mod from the server when she updates?

If I send copy + mod in one commit, and then commit mods three more times,
why shouldn't my peer get copy + (combined mods) when she updates?

Maybe I don't understand the apparently quite narrow use-case you're aiming
to hit.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Wed Aug 8 21:15:57 2007

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.