TFS11 and Source Control Improvements

Now that build is over and we have a Visual Studio 11 we can finally play with I’ve had a brief look at how local workspaces work.

For those who aren’t aware, local workspaces finally removes the number 1, most annoying “feature” in TFS and that is the server-side source control model.

This is the approach where the server keeps track of what it thinks you have on your local development machine and where all checkin/checkout operations require communication with the server making offline work very difficult, and where you can’t make local changes to checked out files because the server wouldn’t be aware of them so all files under source control have the read only bit set.  It’s a major pain.

Now there are valid reasons for this approach related to managing VERY large source repositories (think multi-GB of source) and it’s still possible to use server-managed work spaces if desired, but for the 99% of us that just don’t deal with that sort of volume this is a feature we just don’t need.  TFS 11 sees the introduction of a subversion style approach to source control with the introduction of local workspaces.  Before you get too excited, remember that a local workspace is not a DVCS and TFS doesn’t feature one yet.  That said, Brian Harry in a recent post about source control improvements in TFS11 said the following (emphasis mine):

I’m certain that about this time, I bunch of people are asking “but, did you implement DVCS”. The answer is no, not yet. You still can’t checkin while you are offline. And you can’t do history or branch merges, etc. Certain operations do still require you to be online. You won’t get big long hangs – but rather nice error messages that tell you you need to be online. DVCS is definitely in our future and this is a step in that direction but there’s another step yet to take.

There’s also a number of suggestions about source control on the Visual Studio User Voice site that you may want to vote on so that the team makes this a priority, for example Allow the version control system to be pluggable, or you can create one specifically for a TFS DVCS feature.

Anyway, let’s have a look at a few things in the new developer preview.

What’s on our disk after doing a Get Latest?

Firstly, we see we now have a hidden folder in our workspace root

The folder itself contains a bunch of child folders, which are oddly reminiscent of sourcesafe.  Thankfully it’s not!

These folders course contain GUID based file names:

And each of those files are simply GZipped copies of your individual source files. Opening them with 7Zip reveals the source files  just as you would expect.  Obviously you should leave all this alone and not touch it but it’s interesting nonetheless (or at least it is for me!)

Local Source Control Operations

So leaving that aside, what happens when we make file system changes outside of Visual Studio?

To find out I did a simple copy/paste of a few files and renamed a view in an MVC3 project.  This is what pending changes shows (the other changes are from the VS11 project upgrade)

So the changes are detected but are currently marked as ignored for now.  I get why the copied files are excluded, because they aren’t part of the solution, but I wasn’t sure why the rename was ignored until I realised it had happened because the files I’d chosen were from an MVC3 project and I hadn’t updated VS11 to support MVC3 apps as yet.  This mean Visual Studio hadn’t actually loaded the project so wasn’t actively tracking the file that was renamed.

If I click the “Detected changes (5)” link, we see this:

You’ll note that the rename detection isn’t happening in the developer preview though I expect a way to mark add/delete pairs as renames will be provided before RTM.  We also have a “promote” button to turn the excluded changes into included ones.  Pretty simple.  You can also right click files to ignore them (such as upgrade reports, backup folders, etc) so that they don’t constantly sit in the “excluded files” list.

Once we include the files we want, we see this:

Nice.  Now, when we’re offline we can’t check in with a local workspace.  We have to be connected.  When we are, we can click the Check In button and we’ll get a notification message with a link to the Changeset we just added

Local Exclusions

In git, mercurial and other source control systems there are usually configuration files to control the files that source control will ignore (i.e .gitignore and .hgignore) and they are located in the same folder as the source itself so that they can be checked in and shared across all team members.

In TFS there is only one global exclusion file, and it contains all your local exclusions.  It lives in C:\Users\Me\AppData\Local\Microsoft\Team Foundation\4.0\Configuration\VersionControl\LocalItemExclusions.config and looks something like this:

    <UserExclusions>
      <Exclusion>c:\temp\tfspreview\scrum project\Trunk\DemoAppSolution\UpgradeLog.XML</Exclusion>
      <Exclusion>c:\temp\tfspreview\scrum project\Trunk\DemoAppSolution\_UpgradeReport_Files</Exclusion>
      <Exclusion>c:\temp\tfspreview\scrum project\Trunk\DemoAppSolution\Backup</Exclusion>
    </UserExclusions>

I’d prefer a local exclusion file (e.g. a .$tfsignore) to live at the solution or workspace root and I’d also prefer it to be glob or regex syntax instead of and XML document, but at least we have something. It’s a start.

Finally, if you want to play with local workspaces you’ll need access to a TFS11 server.  The hosted TFS preview service works well for this and if you try doing source control operations over a 3g connection you really feel the difference between local operations and server calls.  Alternatively you can download the TFS11 developer preview from MSDN subscriber downloads and install your own TFS server to have a play with.

All up, this is a well overdue improvement in source control and should alleviate some of the pain we all feel when dealing with TFS.