You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John <js...@ecclescollege.ac.uk> on 2005/05/16 16:22:59 UTC
Blame issue
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
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blame issue
Posted by Daniel Berlin <db...@dberlin.org>.
On Mon, 2005-05-16 at 16:22 +0000, John wrote:
> 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?
No, not yet.
and blame is doing it the other way around right now (IE 607 to 610, not
610 to 607)
You get different results depending on the LCS algorithm used, which
direction you blame in, blah blah blah.
Blame is not an algorithm where this is always a single correct answer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blame issue
Posted by kf...@collab.net.
John <js...@ecclescollege.ac.uk> writes:
> The problem still occurs in the tiny repos, but I think it's a
> 'leading whitespace' problem - not a bug in SVN.
>
> In my revision r609 I enclosed the block in 'try {}', which obviously
> increased the indentation. I guess this is making SVN think every line
> got rewritten... but TSVN is set by default to ignore leading
> whitespace: it shows no change back to 607.
>
> As a feature request (I assume the Blame work is done server-side?)
> maybe Blame should ignore leading whitespace too?
You could just add a note to
http://subversion.tigris.org/issues/show_bug.cgi?id=2121
and maybe adjust the summary to say "diff/blame" too.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blame issue
Posted by John <js...@ecclescollege.ac.uk>.
<kfogel <at> collab.net> writes:
> It's fine to mail it privately to me, yes. (Did you verify that the
> behavior still happens with this smaller dataset?)
The problem still occurs in the tiny repos, but I think it's a 'leading
whitespace' problem - not a bug in SVN.
In my revision r609 I enclosed the block in 'try {}', which obviously increased
the indentation. I guess this is making SVN think every line got rewritten...
but TSVN is set by default to ignore leading whitespace: it shows no change back
to 607.
As a feature request (I assume the Blame work is done server-side?) maybe Blame
should ignore leading whitespace too?
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blame issue
Posted by kf...@collab.net.
John <js...@ecclescollege.ac.uk> writes:
> > Can you give us the data (say, a dump of your repository) and a
> > reproduction recipe saying the exact line and stuff?
>
> Ok to email you a tiny test dump privately? It's 200k zipped. (I
> extracted a few revisions from the main repos, and committed them to
> a test repos).
It's fine to mail it privately to me, yes. (Did you verify that the
behavior still happens with this smaller dataset?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blame issue
Posted by John <js...@ecclescollege.ac.uk>.
<kfogel <at> collab.net> writes:
> > 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?
> >
> 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?
Ok to email you a tiny test dump privately? It's 200k zipped. (I extracted a few
revisions from the main repos, and committed them to a test repos).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blame issue
Posted by kf...@collab.net.
John <js...@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...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org