New Semantic MethodHist is now out! Monday, October 14, 2013 Pablo Santos news 6 Comments

IMPORTANT: Take into account that the Plastic SCM installer in .NET 4 explained below will not work with the "regpkg" mechanism in Visual Studio 2005, 2008 and 2010, so be advised that the Visual Studio package won't work in those versions. This is due to the target framework used in this installer: .NET 4 is much newer than Visual Studio 2005 and 2008, and regpkg don't work in VS2010 with .NET 4 assemblies. For this reason, use Visual Studio 2012 and 2013 to use Method History from the IDE.

Have you heard of the new CodeLens in Microsoft Visual Studio 2013 + TFS? Well, we’ve just released “Semantic Method History” which is… well, CodeLens done right!

We’re very happy to announce Method History since it is the first application of the SemanticMerge technology inside a core Plastic SCM feature and we think it will be the starting point for many more exciting new features.

What is all these CodeLens/MethodHist thing all about?

Version control systems hold an enormous amount of data that, properly mined, could provide a greater insight on why code were changed, helping developers on a daily basis.

If you’re a .Net developer you must have heard of CodeLens, a great new feature in Visual Studio 2013 + TFS which decorates every method in your C# file with useful version control information like how many times it has been modified and when, on a per method basis.

While certainly great, we’re happy to announce our second release of “methodhist” which is now powered by our Semantic Diff technology, and is able to break some of CodeLens limits which are the same we had in “methodhist 1.0” back 3 years ago!.

The limitations of the first generation

Let’s go step by step: we will start with a very simple file like the one below:

And then we will move the method down and make a small change on it:

As you can see CodeLens does a great job and despite of the fact that the method has been moved to a different location within the file, it still calculates its history correctly.

Let’s now try a slightly more complicated case: what if now we move the method inside a subclass... ouch! CodeLens says the method has now only 1 change, it doesn't now it is the same method anymore!

Not being able to track code moved inside a different class within the file is certainly a limitation, we know it rather well because he had the same issue 3 years ago with the initial version of methodhist :P

Let’s now try something different: let’s move the method back to the original class and let’s do a simpler but very common change: let’s rename the method...

Oooouch!!! Again the CodeLens engine can’t track the operation and will make us believe we have a newly created method... Too bad.

Enter the SemanticDiff powered method history

We used to share CodeLens limitations (again, 3 years ago!) but now we’ve just releasing a new version of MethodHistory that is based on our SemanticDiff technology and hence it can track methods (and properties, and classes…) not only when they’re moved to a different location within the same class, but also when they are moved to a different subclass, to a different class within the same file or even when they are renamed!

The big difference between this current version and the previous generation (and presumably with CodeLens too) is that before we just walked the file version history locating the method by name, which is pretty naïve … but now we are able to calculate semantic differences between versions and hence do a much better job locating the methods, properties and so on.

So, let’s check how method history handles the case where CodeLens failed:

Please note how it tracks:

The method being changed and moved from class Program to program.SubClass.

In the last step (the first one showed in the screen, since it shows the changes by date in desc order) it says (in a long line) how the method has been moved back to the Program class, renamed and modified!!!

As you can see it tracks perfectly what has happened identifying “move” and “rename” operations.

CodeLens does an awesome job with the editor

Yes, while I slightly criticized the inner method tracking calculations of CodeLens :P, I’ve to admit that they do an awesome job in the editor.

You’re able to start editing a file and know whether a method has been frequently modified or not, which gives you a great idea of how dangerous the modification can be and warns you about previous issues and so on.

Right now our method history is not integrated this way with the editor: you’ve to right click on a method and find its “history” which is also very good but doesn’t give you the quick overview that CodeLens provides.

Of course we’re working on it: we’re not as good with Visual Studio editors as the TFS team is (for obvious reasons! :P) but we will do our best to come up with extra information in the VS editor (and most likely Eclipse too) as a first step towards some sort of clever version control data mining aimed to put all the power of historical data in the programmer’s fingertips.

Comparing the new method hist with CodeLens

Let’s go for a quick compare between the two:

Feature CodeLens Plastic SCM 5.0 MethodHist Track a method history Yes Yes Track renames No Yes Track moves to different classes No Yes Great VStudio editor integration Yes Not yet! (ouch!) Language support .NET languages C#, Vb.net, Java and soon C, Delphi and many more (basically everything that SemanticMerge supports)

How can you give a test run to methodhist?

Just go to our downloads page, then go to “labs” (where we place the very latest!) and grab the latest Plastic SCM 5.0, but remember to download the .NET4 version which is the one you will need to run MethodHist.

Once you download and install release 5.0.43.490 (or higher) with .net 4.0, then you can launch MethodHist from two different places:

1) You can go to the Visual Studio editor (remember you've to install the Visual Studio package!), right click on a method (or property, or anything!) and click on "show semantic history":

2) Alternatively you can achieve the same from an "annotate view" as the figure below shows:

What is next?

Well, we are working on a couple of very interesting things:

Code editor integration.

Track methods (and any element) across files! (Yes, the super feature you were looking for).

Providing statistics about “hot spots” in code: methods that were most frequently modified, methods involved in bug fixes and so on.

Enjoy!