> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 23 augustus 2011 20:51
> To: Bert Huijben
> Cc: 'Julian Foad'; 'Neels J Hofmeyr'; 'Subversion Development'
> Subject: Re: diff copyfrom, and other inconsistencies [was: Re: diff --
> summarize]
>
> On Tue, Aug 23, 2011 at 07:01:18PM +0200, Bert Huijben wrote:
> > Note that one of the reasons we abandoned this approach here and in the
> > update editor was that there was no way to know when the revision was
> > copied.
>
> What do you mean, abandoned it "here"?
> AFAIK diff never used this.
>
> > E.g. there might be 100 new file revisions at the new path, after the
copy
> > was performed and you would still get it reported as a copy via the
editor
> > callback. We just send the previous path for additions.
>
> Why is this a problem for diff?
> If the copy happened anywhere within the diffed revision range -rN:M,
> I want to see the copy event. Even if there are subsequent edits on
> the copy destination path within the same revision range.
The problem is: You never know if the copy was done within that range.
Assuming N < M
You can get the information that the file was copied *from* N-1000, while
that copy was performed in N-500.
You really get where the file was copied *from*; not in which revision the
copy was performed. So if it is a copy from ^/iota_at_r1 you get that
information when you perform a 'svn diff ^/something -r 10000000:20000000'
(or you get nothing if the server can somehow find that the information is
too unrelated).
For diff you want to know when the copy occurred before you can use the
information on what it was copied from.
The only information copyfrom_rev gives you that it was copied sometime
after that revision and that instead of a delta against the empty stream you
receive a delta against that specific node at the copyfrom revision.
>
> > (The update editor approach also had different problems though)
> >
> > Making this more reliable requires editor changes or further requests to
> the
> > repository to validate the result.
>
> Which kind of reliability enhancements are you referring to?
For the update editor we interpreted the copyfrom revision as a revision in
a range where one of the values wasn't properly defined. (See some issues in
our issuetracker on how this could break your working copy)
Bert
Received on 2011-08-23 21:11:14 CEST