Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
This is the third post in the series on “Developers are Raving Fans” TFS features. The first post was on workspace improvements, the second on merging and this is kind of a wrap up post that covers the rest of the version control improvements. There’s a few more that are in progress that I’m not quite ready to talk about yet but this should cover the majority of what is left.
Probably the biggest thing I haven’t talked about yet is the changes to Team Explorer and the Pending Changes window. I’m going to do a full post in the future on the overhaul we have done to Team Explorer so for now I will just focus on a small part of it. The biggest thing you probably need to know is that the Team Explorer tool window is no longer just a simple tree control. It is now a “canvas” in which we aggregate a number of experiences and allow you to navigate between them. One of the changes we’ve made in the process is to merge the Pending Changes window into the Team Explorer.
The UI I’m going to show you here is not final – we’re still tuning and tweaking it (especially the navigation) but it’s getting there. Overall our goal here is to streamline and remove clutter – in tool window count, complexity and visual overload. Here’s a picture of the new Pending Changes page in Team Explorer and some comments on the changes below.
Some things I want to point out:
As you can see, additional commands are under the “More” drop down:
Overall I think the experience around managing pending changes is an improvement.
When we were developing TFS 2005 (oh, it seems so long ago), we built it to show everyone using their domain name (e.g. redmond\bharry) everywhere in the product. Late in the beta, we got overwhelming feedback that that was a terrible thing for many customers. Many customers have seemingly random sequences of numbers and letter for windows usernames – so they look like mycompany\Q27f01. And no one has any idea who that is (maybe not even the person who owns it ). It was late enough in the product cycle that we couldn’t make a wholesale change throughout the product so after much going round on feedback, we settled on changing work item tracking to use “friendly names” (e.g. Brian Harry) and the rest of the product to use domain names (e.g. redmond\bharry). That quelled the uproar and then somehow, we never found the time to “finish the job” in TFS 2008 or TFS 2010. Well, we finally have. Now friendly names show up everywhere in the product that a user name shows up. The ultimate driving requirement that made us do this now was that there are no domain names on the internet (Google, facebook, live ID, etc) and in order to show useful names on our hosted service, we had to significantly rejigger how we manage user names.
Here’s a screenshot of source control explorer where it’s showing my full name rather than my domain name:
To ease the transition for people who are so used to domain names (for those that are used to them in version control), I think just about everywhere (in version control) we accept a user name as input, we’ll take either the friendly name or the domain name and do the same thing.
One of the things that I know no one likes is modal dialog boxes stacked on top of modal dialog boxes on top of yet more modal dialog boxes. In TFS 2010, we had way too much of that. The most serious downside is that the modality causes you to be locked into that part of the UI and unable to access other parts of the UI to investigate related information. Also the stacked dialogs is confusing/cluttering and we have to introduce new instantiations of commands because you can’t access the main menu/toolbar, etc. We’ve taken steps to reduce modality around the product. More things show up in document well, in the Team Explorer well, etc. The checkin experience I showed you above in the Team Explorer window is one example (we now use that from many more places in the UI than we used to use the pending changes window). Also having “Compare” use the VS editor in the document well gives a kind of non-modal experience relative to using an external diff tool. Another example I want to talk about is shelvesets.
The whole shelveset experience used to be a stacked modal dialog experience. None of it is modal now. If you looked closely at the “More” context menu I showed in the pending changes section, you saw a “Find Shelvesets” option. This is the analog of the old “Unshelve” button in the 2010 pending changes window. However, rather than launching a modal dialog, it opens a new pane in the Team Explorer window that looks something like this:
A couple of things to note here:
Change set details from many places (like history, annotate, etc) will also be non-modal now.
In my first post in this series, I talked about the offline, and responsiveness advantages of local workspaces that don’t have to contact the server to do everything. We’ve also done work around the UI to make things that do have to contact the server more responsive too. We’ve done this by making several more operations async (some things already are – history, annotate, source control explorer). Some of the asynchronous changes we’ve made rely on the modality changes I talked about a second ago. It’s hard to make waiting for a modal dialog asynchronous Are you going to go start working on something else and then have the modal dialog randomly pop-up at some point in the future?
Some examples of asynchronous work we’ve done include:
There are certain things that have significant interaction with the VS project systems that are hard to make async. Other than that, probably the biggest operation that we haven’t gotten around to making async yet is “Get latest version”.
I blogged about this (with screenshots) in my latest Power Tools post. We added rollback in the UI in the latest Power Tools for TFS 2010 but we’ve also added it to the TFS 11 product. It’s great to have this long standing request in for good.
When TFS gets files on to your local disk, it always sets the file modification time to the date/time that the get operation happened. There are some work practices where this is problematic. Some practices use the date stamp on the file for incremental deployment or other kinds of change management. SourceSafe had 3 options for setting the time stamp on files:
TFS 2010 and before only supported option #1. In TFS 11, we have added support for option #3. It can be set on a workspace by workspace basis. We plan to add support for #2 in the future but haven’t gotten there yet.
Our Team Explorer Everywhere client runs on Unix. One of the things you have to deal with on Unix is the file attributes – particularly the execute bit. It’s an attribute of a file that really needs to be saved and restored or it messes things up pretty much. TFS 2008 had no support for this kind of thing. In 2010, we added a property system with the goal of applying it in these kinds of scenarios but didn’t get around to adding branching and merging semantics to it so it wasn’t sufficient to carry Unix file attributes. In the meantime the Team Explorer Everywhere team built a work around of storing file attributes in a “.tpattributes” file but it’s an incomplete solution.
In TFS 11, we are rounding out the properties mechanism and will be building first class Unix file attributes support. Basically, now you can attach properties to a file in version control and expect them to behave “properly” across all version control operations. Although Unix file attribute support will be the first feature incarnation on top of this, the #2 scenario for restoring file modification time should be able to follow reasonably quickly on its heels.
This isn’t going to sound very impressive but in my upcoming post I’m going to talk about some very cool features that build on this. In TFS 2010, we introduced a property system that allows you to tag properties on objects (I talked about this a bit in my Unix file attributes section). However, we didn’t have specific support for properties on shelvesets. In TFS 11, we’ve added that. It’s a general purpose extensibility mechanism. You can attach properties to a shelveset and their access is controlled by the permissions on the shelveset. Also they are deleted when the shelveset is deleted, etc. Give me a week or so and I’ll tell you why this is a very nice feature to have
That rounds out most of the version control improvements under the “Developers are Raving Fans” theme. As I said at the beginning there are a few more thing in the pipe that I’m not ready to commit to yet but what you’ve seen so far is most of it. And it’s quite a lot of stuff – 3 pretty long blog posts to cover it all. And there’s more “Raving Fans” stuff yet to come – more Team Explorer improvements, build, work item tracking, … I’ll cover the rest in the next few posts.
I hope you like what you’ve seen. I can’t wait until I can share the bits for you to try yourself.