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.

Team Explorer

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:

1. The window has a vertical orientation and shares the space occupied by Solution Explorer by default.
2. The look of the of the list of files is much simpler.  It’s a reasonably compressed tree view and rather than textually writing the change type, give a more visual indication ([+] for add, [oldfilename] for rename, strikeout for delete, etc).  The result is a less cluttered and easier to digest look.  Also, for the case of renamed files, I challenge you to find out what it was renamed from in the 2010 version
3. You’ll notice the checkboxes are now gone.  Instead we have “included” and “excluded” changes.  You can drag and drop, etc between them.  When you check in, only the files in “included changes” are included in the check in.  The excluded changes also includes the detected changes functionality I talked about in my post on workspaces.
4. If you are watching closely, you see that we have an “Add Work Item by ID” command which was something you couldn’t do in 2010 (you could only pick from a query result) and has been a much requested feature.
5. Each section can be expanded or collapse to remove clutter.
6. If you have checkin policy violations, that section will show up and if not, you won’t see it – a nice clutter reduction for those who don’t have policies or violations.
7. A checkin notes section will show up if you have checkin notes defined.  We don’t have any by default any more so you don’t see them in the pane above.

As you can see, additional commands are under the “More” drop down:

Overall I think the experience around managing pending changes is an improvement.

Friendly Names

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.

Reducing Modality

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:

1. I can still filter by shelveset owner (here it’s filtered to my shelvesets – that’s the default).  I can type “Brian Harry” or “redmond\bharry” and I’ll get the same result.
2. I can also filter by text in the shelveset title (the “Type here to filter the list” box) and is darn handy for people who keep a lot of shelvesets (and I’ve seen people with dozens and dozens).  It’s an incremental – as you type filter so you only have to type as much as needed to find what you want.
3. We provide a nicer way of showing how old the shelveset is rather than just showing the creation date.
4. Once I’ve found the shelveset I want, rather than hitting a “Details” button and getting a modal dialog, double click it and get an in place shelveset details pane, allowing me to operate on the files in the shelveset the same way I would on any other.  I’ve included a picture.  Note it looks an awful lot like the pending changes window above.  As a side note, notice that I’ve configured a checkin note (Localization) and that’s now showing up at the bottom of the pane.  I’ve also collapsed the comment section and associated a work item with this shelveset.

Change set details from many places (like history, annotate, etc) will also be non-modal now.

Asynchronous Operations

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:

1. Editing a file is now asynchronous.  Local workspaces help decouple us from the server but we’ve also decoupled all the IDE state updating so editing a file really is instantaneous.
2. Checking in is now asynchronous – you can keep on working while your checkin processes.
3. Find shelveset is asynchronous.
4. Sheveset details and changeset details are asynchronous.
5. File compare is asynchronous.
6. Other things outside of version control are also asynchronous – like opening a work item.  It used to block the UI.

There are certain things that have significant interaction with the VS project systems that are hard to make async.&# 160; Other than that, probably the biggest operation that we haven’t gotten around to making async yet is “Get latest version”.

Rollback in the UI

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.

Restore file modification time

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:

1. The time the file is gotten (this was the default and works very well in concert with make and other similar build dependency trackers).
2. The modification time that the file had when it was last edited before checkin.
3. The date/time that the file was checked in.

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.

Unix file attributes

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.

Properties on Shelvesets

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

Conclusion

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.

Brian