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

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.

--dave

-- 
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