[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: David Glasser <glasser_at_davidglasser.net>
Date: 2007-08-08 21:03:27 CEST

On 8/8/07, Ben Collins-Sussman <sussman@red-bean.com> 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?)

Well, there's no such thing as "extra edits" coming from a repository
because there's no such thing as "copies" coming from a repository now
(at least not from the update driver). But, say, when you use
repos_replay to replay the results of svn-cp-then-edit it certainly
will send you add_file(copyfrom=...) and then a txdelta; I was
assuming you'd make the new update driver do the same thing.
(rename-then-edit is certainly a very common thing to do when you're
working with files (say, Java code) whose contents need to match their
filenames.)

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 8 21:01:39 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.