Comment 7 for bug 438531

On Tue, 2009-09-29 at 15:55 +0000, Ted Gould wrote:
> On Tue, 2009-09-29 at 15:14 +0000, Jelmer Vernooij wrote:
> > This is unfortunately not possible without severe performance
> > consequences. If there is no remove+add this means that the file id does
> > not change, and to prove this we would have to analyse the history of a
> > particular file to see if it shared history with the file it was copied
> > from each time we encounter a file copy.
> I mean, you know SVN a million times better than I, but it seems to me
> that you'd already have to track that information as both of the file ID
> would have to be found, and you could determine that they're the same.
> At that point it's only calculating a diff between them and applying the
> diff.
>
> So if you're looking at a rev like this:
>
> r3
> delete:
> 342340823498 r2 as configure.ac
> copy:
> 342340823498 r1 as configure.ac

Subversion doesn't have anything like file ids (I assume that's what you
mean with the 342340823498?). The only way you can find out if two files
are related is by looking at the output of "svn log" and see if they
both were copied from the same location at one point in history.

> Then you see that the two IDs are the same. Do a:
>
> diff 342340823498 -r 2..3
>
> And record that as the change instead of what was given. I'm unsure why
> you'd have to trace the file back to all it's revisions as we only need
> the difference between the previous one (being deleted) and the final
> one created in the revision we're trying to represent.
We have to trace back to see if they were actually the same file. If
they were not the same file then we have a case where one file is being
copied over another, and we want the file id to change in that case.

Cheers,

Jelmer