Annotate (also known as blame) is now a power toy

[UPDATE 9/8/2006] TFPT is now available in its own small download: http://go.microsoft.com/?linkid=5422499! You no longer need to download the VS SDK. You can find more information about the September '06 release here.

One of the features that we had to cut for version 1 was annotate, which is also known as blame in Subversion. We had hoped to provide a power toy that at least provided the basics, and the Visual Studio 2005 SDK – March 2006 CTP for v2 contains an updated tfpt.exe with support for annotate.

Written by Justin, a developer working primarily on the version control server, annotate downloads every version of a particular file and annotates the output with attributes showing the changeset, date, and user who last changed each line in the file. The current implementation does not show deleted lines.

Most of the time, you will likely run tfpt annotate filename to bring up the viewer, but you can also specify /noprompt to get console output. The optional version provides the ability to see changes up to the specified version. Here is the help text.

Displays the given version of a file along with informationon who modified the line last.

Usage: tfpt annotate [/noprompt] filespec[;versionspec]

filespec Server or local path of file to view history of. /noprompt Prints interleaved output to console instead of GUI.

The annotate viewer is shown in a screenshot below. By default, the content viewer displays only the changeset number. You can use the View menu to display the user name and date, as I have.

When this screenshot was captured, I had selected the line that prints the output. As a result, the changeset information on the left hand side shows some of the changeset information, including the comment. If I had associated or resolved a work item when checking in, that work item would be displayed in the Work Items list.

Finally, the Edit menu gives you the ability to search and go to a particular line number.

This annotate implementation provides the basics, and it will likely whet your appetite for more. While this power toy is not likely to get more features, we are certainly interested in your feedback for what you would like to see in the shipping product.

Cool but why is it so slow? I ran it on a file and it took about 15-20 minutes to pop up the GUI. BTW this is on a project we ported over from another version control system and this particular file probably has about 400 changesets on it.

Yes, it can be slow. Because the internal diff engine doesn’t support some encodings, one of which is UTF-8, the current implementation converts all of the files to UTF-16 before sending them through the diff engine. Unfortunately, the internal diff engine is much slower when processing UTF-16 as compared to a single-byte code page, such as Windows 1252.

We’re hoping to modify the code to skip the conversion if the versions being compared are in an encoding that is supported by the diff engine, rather than blindly convert everything.