Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
In Visual Studio 2013 Update 3 CTP1, we introduced some CodeLens for Git indicators. In this RC update we are completing the work by:
In the CTP1, the authors and change indicators that we introduced did not refresh automatically when source control operations occurred. As a user, you had to manually refresh the indicators using the contextual command (or close and reopen the file)
In this RC, all the CodeLens for Git team indicators now refresh automatically when you:
The refresh occurs when performing these actions from Visual Studio or from any other tool, including the command line.
In Visual Studio 2013 Update 3 CTP1, the authors and change indicators could take some time to appear, especially in the case of source files containing a lot of code elements or having a big change history. When that occurred, we received feedback that the users could not tell if something was broken, or that there were no change, or if it was just taking a lot of time. This was not an issue with the TfVc CodeLens team indicators, as they retrieve pre-computed data from the Tfs server. But since the processing occurs locally on the client for Git indicators, we had to let the user know that the computation was being done.
In this RC, the Git collaboration indicators shows dimmed placeholders while data is being computed, similar to the reference indicator:
Then, as things get computed, the numeric information appears and the color of the indicators get darker:
In addition to the latest author, and the number of additional people who have changed the code element, we now display how long ago the last change happened (31 days ago in this case)
As was explained in the previous blog entry, the CodeLens for Git indicators work with any Git repository. In particular, they also work for Git repositories hosted in TfGit, either on premise, or in Visual Studio Online. In that case, you might be using Tfs to manage your work items.
When you are connected to a Team Project Collection (either from a TFS server or VS Online), and when we recognize that commits were associated with work items, we display another indicator, the Work item indicator telling you the number of work items associated with all the commits involving this code element.
When you click on the indicator, we go to the Tfs Server
And we get the work item details
As in the case of the CodeLens for TfVc indicators, you can navigate to the work items (this will open a tab in Visual Studio), or to the commit, which will appear in Team Explorer.
Of course, as in the case of TfVc CodeLens team indicators, we also changed the changes indicators popup to add the work items associated with commits:
As an aside, you might wonder in the image below some if the instances of the author have a green Lync presence indicator (meaning the author is currently available on Lync), and others show the same author as absent. This is because I did the commits with 2 different credentials (but the same display name). In one case I used my Microsoft Id, and when the organizational ids became available in VS Online, I started using my corporate ID, for which I show-up as available right now.
Here I've double-clicked on the commit, and I can see the commit details in Team explorer.
The reason why CodeLens for Git knows that there are two work items associated with this commit is that the last line of the comment is of the form:
Related Work Items: #1, #3
This way, without any call to the TFS server, the Git CodeLens indicators know how many work items the commits are related to. But they don't know:
CodeLens only attempts to fetch this information when the pop-up is displayed. Therefore it might happen that:
In the case you are not connected to TFS, or are connected to the wrong Team Project Collection, you'll get a message when trying to see the details popup for the work items indicators. If that happens to you, you will need connect to the Team Project Collection. Of course this will probably close your solution, which you will have to re-open, and then things will work.
Note to reviewers: I'm installing a latest RC drop to make a screen copy with the right color for the message
If you are not allowed to access some or all of the work items (or they don't exist), the popup will display information for the work items that could be retrieved and a message informing you that not all of the expected work items could be retrieved.
As always, we are interested in hearing your feedback on this feature.
Please try it out, and let us know.
You know what is more famous than GIT? SSH, SCP and SFTP which are not natively supported in VS and, in general, Window shells (and File/Windows Explorer!)
Couple of reasons:
- Git co-exists with SSH, SCP and SFTP.
- SSH, SCP and SFTP are equally famous protocols and is used by millions everyday. Even Microsoft's own customers on Azure and otherwise, use it heavily.
- There is quite a demand of robust support of these protocols natively in Windows, VS and .NET.
- I think this would be the big news for masses, as compelling as C99 announcement for VC.
Not showing interest to what people would actually use more frequently (due to some old grudges with Linux world) is neither helping you nor us.
I hope Microsoft add CodeLens to VS 2013 Premium too..Please it has no sense to have CodeLens only in Ultimate edition.
Why is this a Ultimate feature only? It got nowthing to do with Architecture or other topics .... It's a bit stretched.
Please add CodeLens to Premium. Most small to medium size companies cannot afford Ultimate.