Does this sound familiar?
my program (n): a gem of algorithmic precision, offering the most sublime balance between compact, efficient coding on the one hand, and fully commented legibility for posterity on the other. Compare YOUR PROGRAM.
Perforce has an even niftier feature: time lapse view. Basically the same thing, but you move a slider back and forth in time, to see how the file looked in the past (and who was responsible for those previous revisions, too.)
[edit http://www.perforce.com/perforce/products/tours/p4v/images/p4v_time_lapse_view_7.gif ]
Wumpus,
Note that the svn blame command also has an alias: praise. I prefer blame, naturally. Praise is for hippies.
It’s interesting when you write some piece of code in an application, and then go back to it 6 months or a year later. It’s your own code, but you might still ask “Who the hell wrote this crap?”
It might be something that you, and the team, all thought was ok and it made it into the final version. Yet, given some time it’s inevitable that you learn things that make you stare in consternation at your old code.
This feature is already some time available for TFS and VS 2005 as a Powertoy, even for the command line according to this: http://blogs.msdn.com/bharry/archive/2006/09/07/744993.aspx
“The upcoming Visual Studio 2008, or at least the Team System flavor of it, finally delivers a feature I’ve wanted for years: it can display the code side-by-side with the person who last changed that code.”
Actually, this has nothing to do with VS 2008. It is available in VS 2005 Team System as well, so I would rather say this is a Team System feature
Source control systems such as SCCS and ClearCase have stored this information for years, although this is a nicer interface.
However, I’ve seen that the biggest culprit is usually ‘guest’ or ‘administrator’, or even worse, ‘test’, since control over user logins has never been that strong.
There’s a saying that goes like this: “Code is like shit - it only smells if it is not yours”.
I quickly read over the comments, and I may have missed something, but to my knowledge no one brought up an extremely obvious point. Everyone is talking about mercurial, git, vim, emacs, blah blah tools tools, but nothing about the obvious human aspect to these types of features.
You are blaming another coder for something they have written. As illustrated by the very first couple sentences in the post, you are all ready inclined to think you are right, and they are wrong. So now you’ve turned yourself into one of those developers. The one that is looking for WHO did something instead of WHY they did it. What is important to the success of a project has very little to do with who wrote it. Take for instance the screenshot you show above. Are you really trying to figure out if Sally sucks at programming, or are you trying to figure out why she added the regular expression?
Unless it is your job to figure out who to fire and who to hire, stop trying to make it your job to figure out who to fire and who to hire. I understand maybe you’d like to go talk to Sally and ask her… but then that is an issue in your commit messages, not your IDE. In open source work, there generally will be someone who becomes poisonous to your project and you will have to ask them to leave even if they are a major contributor. This does not mean you need to constantly think about who owns what line of code. I think this is something that XP warns against, and I might actually agree with.
http://www.extremeprogramming.org/rules/collective.html
I’ve rambled quite a bit here, but I think my point is straight forward. Don’t blame specific members of your team for their code, understand why anyone would have written the code.
The ‘blame’ tool isn’t always so useful. At my current company, we do a lot of work on branches that gets merged into trunk. It’s not always the same person who wrote the code that performs the merge, so you end up having to delve into the full history in any case…
I partially disagree, as the VCS can only resolve conflicts to the point where coder intervention is required. If the time comes and you have to resolve conflicts manually and the IDE just shows you “.rxxx” and “.mine” blocks you can loose precious time.
Oh yes, I definitely agree with that part.
It looks like a really nice feature however the tradeoff between the speed hit when starting up a project plus maintenance issues using SC bound projects isn’t in my opinion worth it (I’m connected to SC over the internet). I can do the same just looking up change history albeit slower and in a less flashy interface.
I use Subversion, Tortoisesvn and VisualSVN for my source control needs and together they’re simply brilliant. I coordinate an open source outlook style list control hosted on Codeplex and found using TFS over the internet to be extremely slow with annoying with credential dialogs popping up every time I opened a project. Then I found SvnBridge which allowed me to us Tortoisesvn and VisualSVN against a TFS backend.
Having used both systems Subversion shines for internet based connections whereas TFS seems to be tweaked for LAN type collaboration. I’m talking here only about the source control side of things of course as TFS also has loads of features to do with testing / work item tracking etc…
Regards
Lee
“It’s interesting when you write some piece of code in an application, and then go back to it 6 months or a year later. It’s your own code, but you might still ask “Who the hell wrote this crap?””
Oh yeah. I have that pattern 
Since you already know who to blame (the other developers), isn’t this feature unnecessary? Or perhaps Microsoft needed a way to keep track of all the bad coders, like a payroll project.
Now if everybody edits the code as administrator , we are back to our sleuthing ways of finding the culprit. Oh well …
re: Ant
Yes I’ve noticed the same thing - if you branch and merge for bits of development, all this fine-grained info is harder to keep track of. Makes me wonder about whether to bother with branches.
“I’d like to know if people that write such comments are writing ‘new’ stuff themselves?”
Well, once I wondered how an editor could automatically rename local variables or members (with looking for new and old shadowing etc.). That was about 1990, but the moment just passed by…
“If not, do they constantly write themselves e-mail complaining their work is not original?”
When someone just has discovered the wheel, I don’t need to have actually invented it for a minor correction. As we all know, microsoft invented the hierarchical filesystem, the windowing system, you name it… Aprops: ‘cvs annotate’, but you can blame emacs for only showing the output in a separate buffer, not as decoration to the file buffer.
Normally if I saw some checkin for “Administrator”, I’d assume that he is merging branches, or if the date is really old, this is the initial import into source control.
CVS annotate command was available in Emacs back during the Jurassic. Here is the link to the Emacs manual:
http://www.delorie.com/gnu/docs/emacs/emacs_137.html
I would propose a new law - “Any feature of a GUI based IDE has been available in Emacs for at least 10 years”…
…richie
