You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/08/08 18:48:12 UTC
Re: svn commit: r25992 - trunk/notes
On 8/8/07, sussman@tigris.org <su...@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?
--dave
--
David Glasser | glasser@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
Re: svn commit: r25992 - trunk/notes
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 8/8/07, David Glasser <gl...@davidglasser.net> wrote:
> 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.)
>
Oop, you're right. I'll fix the notes. It still doesn't change my
plan, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25992 - trunk/notes
Posted by David Glasser <gl...@davidglasser.net>.
On 8/8/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 8/8/07, David Glasser <gl...@davidglasser.net> wrote:
> > On 8/8/07, sussman@tigris.org <su...@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@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
Re: svn commit: r25992 - trunk/notes
Posted by David Glasser <gl...@davidglasser.net>.
On 8/8/07, Vlad Georgescu <vg...@gmail.com> wrote:
> Ben Collins-Sussman wrote:
> > On 8/8/07, C. Michael Pilato <cm...@collab.net> wrote:
> >
> >> 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.
> >
> > No, you're right about the server sending an add_file(copyfrom) +
> > extra txdeltas. It's definitely possible.
>
> Are we talking about txdeltas against the copy source at rBASE, or at
> the revision in which the file was copied? I think we want the former,
> but we might not be able to determine rBASE for the source...
I think for first approximation, the server does its best to determine
rBASE, and if it's wrong the client just falls back to get_file again.
--dave
--
David Glasser | glasser@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
Re: svn commit: r25992 - trunk/notes
Posted by Vlad Georgescu <vg...@gmail.com>.
Ben Collins-Sussman wrote:
> On 8/8/07, C. Michael Pilato <cm...@collab.net> wrote:
>
>> 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.
>
> No, you're right about the server sending an add_file(copyfrom) +
> extra txdeltas. It's definitely possible.
Are we talking about txdeltas against the copy source at rBASE, or at
the revision in which the file was copied? I think we want the former,
but we might not be able to determine rBASE for the source...
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25992 - trunk/notes
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 8/8/07, C. Michael Pilato <cm...@collab.net> wrote:
> 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.
No, you're right about the server sending an add_file(copyfrom) +
extra txdeltas. It's definitely possible.
Before the update-editor-driver transmits an add_file(), it would call
svn_fs_closest_copy() to find a copy source. If one is available, it
then transmits add_file(copyfrom=...), then some extra 'combined'
txdeltas (via svn_fs_get_file_delta_stream()). If no closest_copy is
available, then it sends a normal add_file() and a txdelta containing
the whole file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25992 - trunk/notes
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> On 8/8/07, David Glasser <gl...@davidglasser.net> wrote:
>> On 8/8/07, sussman@tigris.org <su...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r25992 - trunk/notes
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 8/8/07, David Glasser <gl...@davidglasser.net> wrote:
> On 8/8/07, sussman@tigris.org <su...@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?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org