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

Re: bug? blame with -g does not follow copy history

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-03 19:27:12 CET

On Dec 3, 2007 8:46 AM, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Hi,
> When blaming a file with the '-g' option, all changes previous to a
> rename are ignored. The following script illustrates the problem:
> svnadmin create blamerepo
> svn checkout file:///d:/blamerepo blamewc
> echo line1 > blamewc\file1
> echo line2 >> blamewc\file1
> svn add blamewc\file1
> svn ci blamewc -m ""
> svn mv blamewc\file1 blamewc\file2
> svn ci blamewc -m ""
> Now, do the blame:
> svn blame blamewc\file2
> 1 kueng line1
> 1 kueng line2
> but:
> svn blame blamewc\file2 -g
> 2 kueng line1
> 2 kueng line2
> As you can see, the reported revision is the one *after* the rename
> operation, not the one where the line actually got changed.

I'm not yet familiar with the blame -g implementation; hopefully Hyrum
can explain...

> Also, this only seems to happen if the 'server' knows about merge
> tracking, because when I try the same on the Subversion trunk with
> /notes/tree-conflicts/scratch-pad.txt (which got renamed too), there's
> no 'real' difference in the blame output with/without the -g option.

Indeed, blame/log -g should error out if the server does not support
merge tracking.


David Glasser | glasser_at_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
Received on Mon Dec 3 19:27:25 2007

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.