views:

62

answers:

2

I have a file in my Subversion repository named "Foo.cs". When I run the command svn blame Foo.cs the output looks something like this:

1000 dave 
1000 dave
2000 dave
2000 dave
9999 dave
1000 dave
9999 dave

The only thing that I can think of is that from revisions 1000-9000, Foo.cs had the "svn:mime-type" property set to "application/octet-stream". However, since r9000 Foo.cs has no such property since it is (and always has been) a text file.

Also, I've already tried to use svn blame Foo.cs --force without success.

Does anyone know how to fix this problem?

EDIT: At r1000, the history was truncated (svn log Foo.cs doesn't report anything earlier than this) because the branch was moved to a different spot in the repository by hand instead of using svn mv. However, it's hard to imagine that this is the cause of the problem because svn blame works on every other file in the repo.

A: 

You'll probably find your answer by looking at what happened in change numbers 9999 and 2000. Or, simply look at all the changes for the file (svn -log -v Foo.cs) and see if any other properties might have been changed.

Ether
+1  A: 

The only thing that I can think of is that from revisions 1000-9000, Foo.cs had the "svn:mime-type" property set to "application/octet-stream". However, since r9000 Foo.cs has no such property since it is (and always has been) a text file.

I think that's your answer. Experimenting with Subversion 1.6, any time I have a revision in history with svn:mime-type set to application/octet-stream, I get Skipping binary file from svn blame.

Subversion may have set the property automatically, if it detected the file as having non-text content.

I can't think of a good answer to fix the situation. You can delete and re-add the file again. This will truncate history, but at least svn blame will work for newer revisions.

dave