Why I like TFS :)

by Jesse Houwing

As a response to Joe Ferner's post on why he dislikes TFS. I'll first touch upon the items brought forward by Joe. Some of them are just true, and I won't put too much effort in those, but some I just don't agree with.

Joe's complaints

CodePlex -- First there was the SVN bridge (yes, someone hated TFS enough to make a product to make it look like something else) then Microsoft just caved and supported SVN directly. Not really a problem with TFS, it's just an indication that others feel the same way as I do.

And now they're adding GIT support as well. Not because they hate TFS as much, but because they want as many people to use their open source sharing tool for sharing Microsoft/.NET related projects. For many enterprise users the ability to use TFS is great, they use it in their daily job and it's their tool of choice. For me that is the case as well.

Others, who aren't using TFS in their daily routine, but are more accustomed to GIT or SubVersion prefer their tools. This is especially true for many of the people contributing open source projects to CodePlex. The best thing is that you can use any of the tools side-by-side, allowing people from all sides to contribute to your projects.

And you can install these bridges on your local TFS instance to allow cross team collaboration while still retaining one central repository for easy backup and restore, centralized reporting and centralized security.

Size -- I guess Microsoft doesn't really like it either since they don't even ship it with Visual Studios, if you do need it, its a separate download and a big one at that -- 200MB+. Subversion, Tortoise SVN, and Ankh on the other hand combined are less than 15MB. How they filled up 200MB I have no idea, maybe they installed a client that doesn't suck somewhere I don't know about.

Team Explorer ships with the Visual Studio Shell included. Which explains the large size of the download. They might have been able to ship a installer that just includes the Team Explorer bits which you could use if you already had Visual Studio installed. They decided not to. Again, for me not much of an issue, I use the Visual Studio Ultimate

They don't ship it with the Visual Studio versions that don't include a license to access TFS in their product price. For these people they provide the downloadable version. If you look at it from that perspective it's quite logical.

Read-only Files -- Every file on your system is read-only. Why does everything need to be read-only. If I'm in another editor and I want to make a change to a file, I need to switch over to VS and check out a file for edit. This is rediculous.

Agreed. And they're going away. To make your life in other editors easier, you could always install the Team Foundation Server Power Tools, which add Windows Explorer integration. Allowing you to check out a file from every File Open... dialog in Windows.

Identical Files -- I just want to see what changed. Why does TFS insist upon showing me all the files even if they are identical. Call me crazy but I like to see what files I actually changed when I check in. Someone told me there is some command line tool to see this but that's just silly.

Never felt this as an issue. TFS won't actually create a new version for identical files and your checkout will be undone. I usually make it a habit not to check out files if I don't change them. As others mentioned in the comments of the original post, there's a "undo unchanged" option in the Pending Changes window which will actually release any file you didn't change.


Code reviews/update -- On my current project I'm the project lead and I like to review the junior developers code when I update my code. Yeah, I can't do that, or I haven't found the button yet. Nor can I find the button to view a particular revision without finding a file that was part of that change and viewing it's history.

There's multiple ways to enforce a review process through TFS. The simplest way is to take away someones check-in rights and let them shelve their work. You can then review the shelve and check the changes in if you're satisfied. Ivo Manolov has written a nice post about how to do this.

Should you prefer a post-mortem review process, then you can use the View History... menu item in the Source Explorer window to quickly look up the most recent changesets. Then choose Changeset details to view the files changed during the check-in.

Visual Studio 11, together with TFS 11 will add a much more extensive review process to the Team explorer experience. I gave a presentation on these features at the Dutch TechDays conference a month ago.

There are two open source projects (TFS Code Review Process and TeamReview) that add similar Code Review features to TFS.
Deleted files -- Team Explorer doesn't show them by default. This took me a while to figure this one out. You need to go into VS options then find TFS and then click show deleted files. Why is this not on by default and why isn't there a button to toggle this setting in Team Explorer.

There's a free add-in available that adds the item to the Source Control context menu's. Plus a few other useful items, such as Destroy (delete with history), changing the data on your file system to the date the file was last changed in source control.

And most important: The ability to drag and drop files in the Source Control window.
Project file modification -- We have some people working inside a VPN and some out, the TFS server name is different depending on where you sit. Since the solution file stores the connection string to TFS it's constantly getting checked in.

The way bindings are stored inside Visual Studio projects and solutions is troublesome. I hope they will remove this eventually. This isn't really a TFS issue, but more a Visual Studio issue. The same thing applies to many source control systems that integrate with Visual Studio through the Source Control API.

Proper installation of TFS with a proper globally unique domain name would solve this. But I agree it's irritating if not setup correctly. Ed Blankenship has a great post on using friendly names in your TFS environment. You could also add the internal name to your host file and make sure that it resolves to the proper (VPN) ip address as a workaround.
Everything needs to be in the solution -- If you have a bunch of support files or non-.NET files, all of them need to be added to the solution or they don't get checked in or out. VS doesn't help you with this either because you can't have a solution folder map to a directory.

You can map a folder to filesystem and use the Source Control tab or the Windows Explorer integration provided by the Team Foundation Server Power Tools to work

You can add files to source control from the Source Control tab in Visual Studio without having to add any file to the Solution.

I actually tend to do a get-latest before opening my solution, as it's much faster to get the latest version without having the solution open in Visual Studio. That way you always grab all the other files as well


Integrating with non-.NET developers -- If you have a mixed development environment (Java, Ruby, etc) like we do. You need to run TFS and something else because all the non-.NET developers can't use TFS especially if they are on a Mac. Usually the something else is much better anyway so you might as well use that instead.

In comes Team Explorer Everywhere which provides both a GUI and command line utils and the Team Foundation Server Build Extensions. There's even an SDK to build your own TFS extensions using Java. Team Explorer Everywhere 11 and TFS 11 will also extend support for case sensitive file names. They're also providing a SourceSafe wrapper which allows any development environment that runs on Windows and that supported SourceSafe to connect to TFS. This includes Visual Studio 6, the old Rational toolset, PowerBuilder, Enterprise Architect and more.
Working offline/Speed -- If you ever travel relax and take a nap because you won't be developing. Everything you do talks to the server and that in turn makes it slow. Open up a file and start making changes, to the server you go. Move a file, to the server you go. Diff a change you made, to the server you go.

Agreed. This isn't working as well as it could. There's a Go Offline option to work offline but it sucks. Local workspaces will greatly improve the offline experience in Visual Studio and TFS 11.

Workspaces -- Who ever came up with the concept of workspaces at Microsoft should be ashamed of him/herself. They are just a stupid idea. If you want two copies of the same project checked out (I do it with SVN if I'm working on a quick bug fix and a big feature at the same time) good luck because I can't figure it out.

You can create multiple workspaces on the same machine. You can do it from the commandline or through the Team Explorer UI.

And you can use Shelvesets to accomplish this as well. Visual Studio 11 will actually provide a very nice workflow for temporarily suspending work on one item to work on another.

Server isn't free -- 'Nuff said.

There has long been a workgroup edition of TFS which is free for up to 5 members. And TFS 11 will ship with a TFS Express edition which will be free for small teams. You can get free TFS for open source projects on Codeplex and for now the Team foundation Service Preview is free and will probably be relatively cheap to use when it goes into full production mode.

The cloud hosted version comes with a number of nice advantages that are even hard to get by in the current full product version. Such as world wide distribution though Azure. Federation support with the ability to add your won identity providers. Cloud based on demand build servers (add new agents if the load requires it, put them to sleep when you don't need them). Central patch management from Microsoft (optional).

From a centralized IT perspective, the Team Foundation Services will be a very lucrative way to store your sources and work items securely for a very low cost of ownership. And it will be a great way to enable cross organisation collaboration with enterprise grade security built in.

Some complaints by others in the comments

Rollback experience is horrible

Again the Team Foundation Server Power Tools really improve the experience. You can use Rollback Changeset to remove the changes added by a specific changeset from the History panel. Or you can rollback a file or folder from the Source Control window.

All in two clicks!
And you can also accomplish this directly from the commandline. All it takes is to run tf rollback, followed by tf checkin.

Merge UI stinks

Agreed. Luckily you can configure any tool you like. And to boot, Microsoft is completely re-doing the merge experience in Visual Studio 11. The new merge tool also supports context aware merges for XML files, which no longer treats it as plain text.

Context aware merges for source code can be expected after project Roslyn has been shipped. Once that happens, it should be possible to reformat all your sources and still have the merge tool understand what exactly was changed and provide a proper merge experience (though you might have to reformat your sources again afterwards ;)).

Renaming files under Source Control

This used to be very bad in TFS 2005 and 2008 in certain conditions. But in 2010 they changed the way files and versions are stored. This greatly improves how files are handled under the covers.It's still bad sometimes, especially when you're doing merges between two very diverged source trees, but I find these things to be expected.

The introduction of the Local Workspaces should improve most simple rename scenario's a lot as well.

Project system gets in the way of productivity

Many of the other complaints are not as much about TFS, but more about the Visual Studio Project system. If you'd use TFS for a Java project, using Eclipse you'd have a much better experience in this department. It's the way Microsoft has been working with solutions and projects over the years. And for the most part you really need to learn to work with them. The same thing applies to using Visual Studio projects in any other Source Control tool.

There have been many requests to change how the system works. There have been many requests to remove the binding files. And from a TFS perspective, they don't need to be there. It's a Visual Studio thing.

If there's one item I wholeheartedly agree with on the long list of complaints, it's this one. I much prefer a file system + extension based system over project files that store duplicate information. Funny thing is that msbuild, which is used as a basis for these project files, supports this just fine. You can easily create compile units that gather all *.cs files under a certain folder into one binary. But Visual Studio will not be able to show your project properly in the Solution Explorer.

And why I like TFS over other tools

Stable Visual Studio Integration

Visual Studio is my primary tool of trade. I've tried accessing a GIT project directly from TFS some time ago and couldn't get it working. I tried many of the available tools and finally ended up grabbing a local copy on file system and using the Windows Explorer integration to manage the sources. Not the best experience.

It took quite some time for CVS and later SVN to provide stable integration into Visual Studio. For me TFS has been stable right from the get go.

Extensibility

TFS comes with a great .NET and Java API allowing you to interact with TFS source control and all of the other features from code. There's also a set of extensibility points that allow you to directly interact with the internal processes without breaking existing functionality.

Of course SVN and GIT are open source products, so you can change them to your hearts content. But if you want to get a complete TFS feature set and not just Source Control you're looking at a lot of different vendors, API's and programming models.

As you can see above, there's quite a few free extensions to Visual Studio, which make it easier to work with it. If you feel that certain features are lacking you can build your own extensions and share them with the community.

Integration Platform and Bridges

I already mentioned the SVNBridge and GIT-TFS provide the ability to allow non-Microsoft users to connect to TFS. You can use the tool you like best. For these people Microsoft also provides Team Web Access so that they don't require to have Team Explorer installed to access the other features of TFS.

Apart from those, there is the Team Foundation Server Intergration Tools/Platform. This suite of tools allows you to migrate to and from TFS from a large list of other platforms. Both commercial and open source. You can also use these tools to set up uni- and  bidirectional sync between TFS and other systems.
It's more than just Source Control

An important part left out of the original post, but surfacing in the comments is that TFS is more than a place to store sources. It brings together:

  • a project workspace (through SharePoint) with document storage, wiki's and a team dashboard
  • automated build systems, including virtual lab management, build-deploy-test workflow
  • test automation, including unit tests, manual tests, coded UI tests
  • work item management, including integration into Excel, Microsoft Project (both Client an Server), Microsoft Outlook (through commercial 3rd party products), customisable workflow
  • cross project reporting for very large development organisations.
  • and of course the discussed source control features.

One vendor, many tools

I like the fact that Microsoft provides more than just one way to access the system. There's the Team Explorer that integrates into Visual Studio, the Power Tools that integrate into Windows Explorer and PowerShell, the Team Explorer Everywhere that integrates into Eclipse and the Mac and Linux command line.

If you include the non-source control items, it also integrates into Excel for quick work item management, Project Client and Server for central planning, and a 3rd party product that integrates into Outlook for issue management.

Ohh and there's a web interface which is being extended with a nice agile plan board in the next release (if you can't wait, there's a few 3rd part products that bring this to TFS Web Access right now).

And almost all of these tools are provided by Microsoft out-of-the-box and come with the 200MB installer mentioned before. It allows not only developers, but also testers, project managers and users to interact with the system. Each using their own tool of trade.

It's usually a matter of preference

All in all, I like TFS. It has it's quirks. Just like any other tool out there. If you invest some time to find an add-in here and there you can make your life a lot easier. The same applies to GIT or SVN as there are a lot of different clients out there. Some people just prefer one over the other.

I've used SubVersion, CVS, SourceSafe and Rational ClearCase before, and I must say that TFS is a big step up from any of them at the time I tried them. My last venture into GIT wasn't as successful as I'd hoped, not being able to get stable integration into Visual Studio after multiple hours of hacking on my system.

For me it works. I'd even dare to say that it works just fine :).

Leave a comment.