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

Re: Blame issue

From: <kfogel_at_collab.net>
Date: 2005-05-16 19:00:29 CEST

John <jsparrow@ecclescollege.ac.uk> writes:
> This probably isn't a bug - but no one has replied on the users list,
> so appologies for posting it here:
> I have a .cs file I'm using Blame on. One line that was added in r607,
> and not changed since, is being listed as r610 (HEAD).
> If I use the log viewer in TSVN to examine my file (changes between
> r609 and r610) it correctly shows that a particular line was *not*
> changed in 610. Doing R to R-1 comparisons using TSVN, it shows the
> line was indeed added in 607, and not changed since.
> However Blame (TSVN and command line) seems to think the same line was
> changed in 610. Why should it do that?? I know you've done speed-up
> changes in SVN1.2, is it no longer looking at individual rev changes,
> but instead grouping them together in some way?
> Now, if I export 607 and 610 and use WinMerge to compare, the diffing
> routine does the same as Blame - it doesn't match up the line from 607
> with the same line in 610. But doesn't Blame incrementally compare
> each revision, in just the same way I used the TSVN diff check?
> SVN1.2 rc3 server, rc4 client (TSVN 1.1.5). All Win32. Apache 2.0.54

So why exactly wouldn't this be a bug? :-)

Can you give us the data (say, a dump of your repository) and a
reproduction recipe saying the exact line and stuff?

If blame is assigning a change to the wrong revision, that's bad...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 16 19:36:35 2005

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.