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

bug? blame with -g does not follow copy history

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-12-03 17:46:25 CET


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

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.

This happens with a build from revision 28185.

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.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.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 17:46:57 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.