I used svn blame a lot recently, but never to trace the cause of bugs. I break out the usual tools (debugger and brains) for that. I only resort to blame to understand how a particular odd piece of code came to be (e.g. commented out leftovers that were last touched years ago and forgotten). Even then, I mostly need to see how line changes relate and when they were made. The author is merely a reference of last resort - a pointer to a person who might, with some luck, still remember that he worked on that part.
When I find a bug in code that a colleague has written I simply tell him about my changes to it. That keeps him in the loop and gives me a confirmation that my attempted fix should indeed be OK. Of course, in more formal projects, tickets and code reviews would replace that process.
Blame is not about assigning blame. The feature has a terrible name because it brings up this undesired association. It is about understanding the lineage of the code.
But in svn the feature is actually called "annotate"; "blame" and "praise" are mere aliases for it. To quote the book[0]:
you may find yourself typing svn blame …
or svn praise … instead of using the canonical
svn annotate command form. That's okay—the
Subversion developers anticipated as much,
so those particular command aliases work, too!
An interesting case of Poe's law, applied to command lines: an alias made in jest becomes so successful that users are actually using it for the ridiculed purpose fully believing it's the intended use.
Without looking at the archives, I believe that annotate and praise were introduced well after the initial implementation which used blame as the command. I may be wrong, though.
It seems the command is listed as `blame` even in the v1.0 book, but does even then have the `annotate` and `praise` aliases. In all the years I used svn I firmly believed annotate was the canonical form and it was the one I always used, so I've learnt something here (about svn, and maybe about myself).
Totally agreed! I use `git blame` to look into the history of a piece of code but never think about it as actually "blaming" anyone or using it for bug-hunting.
I only resort to blame to understand how a particular odd piece of code came to be
Right. The idea of downplaying "blame" in corporate culture isn't to conceal where bugs came from; it's to make it more socially acceptable to confess when you've caused a bug, instead of keeping quiet.
"Blame" culture is when people take your transparency and use it to create a scorecard against you, which can quickly become toxic.
When I find a bug in code that a colleague has written I simply tell him about my changes to it. That keeps him in the loop and gives me a confirmation that my attempted fix should indeed be OK. Of course, in more formal projects, tickets and code reviews would replace that process.
Blame is not about assigning blame. The feature has a terrible name because it brings up this undesired association. It is about understanding the lineage of the code.