Wednesday, December 3, 2008

Team Foundation Server - Pros and Cons

So you're shopping for a Source Control server. There are a lot of options out there. I've only used two systems in earnest: Source Safe (SS) and Team Foundation Server (TFS). For the most part, I don't hate too many products / technologies. I'd like to think that I'm a pretty open minded guy. However, I truly hate Source Safe. I despise it. I wish that it would go away and never bother anybody ever again. It is a horribly outdated piece of crap technology that should never see the light of day. If you're thinking about adopting Source Safe for a new project, don't. Just stop. Shoot yourself in the foot. It will safe you time and will be less painful in the end. Alan De Smit does a good job detailing why Source Safe sucks in great detail here.

There are a number of other choices out there. I've been particularly interested in trying SourceGear Vault. I've only gotten as far as downloading the trial - I never got around to installing it. I've used their Source Off Site (SOS) product (it's a client / server piece which provides much faster WAN / VPN access to a Source Safe database - it was absolutely brilliant).

But, back to TFS. Here's some background information that should help you get a feel for what you're getting into...

  • It's fast as hell, at least compared to Source Safe. It's designed to run over a WAN and it communicates with the server via web services. Getting latest is very efficient because TFS only gives you what you need and doesn't need to check every file in your solution.
  • Integrates ever so nicely with Visual Studio. It fits like a Glove into Visual Studio 2005 / 2008.
  • Atomic Commits. In other words, if one file doesn't make it into a checkin, none of them make it. That's the way it should be.
  • Comes with Team Build, which provides functionality that I hear is relatively similar to (or so I've heard).
  • The work item subsystem is pretty sweet. It has lots of features out of the box and is very extensible. This is where you can store bugs, work items, etc. It's not as full featured as Clearcase or one of those systems, but it's adequate for doing most items.
  • Pretty solid extensibility. You can add your own check in policies, access the work item / source control via API (either via the client API or through the service interface).
  • Costs an arm and a leg. You can get a 5 person workgroup edition (for free with your MSDN subscription), but you'll have to saw off your arm (and leg) to buy enough seats for 6 people.
  • Setup is a pain in the ass. There are a bazillion (well, not that many) prerequisites and it takes forever to get them all installed (SharePoint, this, that, etc). Setting up the data tier on another machine takes some work as well. It's definitely not a turnkey, just run Setup.exe and accept the defaults installation.
  • Because installation is such a pain, recovery is a pain unless you backup the TFS as an image. The good thing is that you only need two things in a worst case situation to restore a TFS server: The SQL Server database backup and the report private key. Well, you can probably live without the key, but the instructions say that you need it.
  • The work item system in its current implementation does not support hierarchical data. That (very important) feature is supposed to be supported in TFS 2010. IMHO, you need a hierarchy to do a proper breakdown of any non-trivial project. I actually moved all the breakdown information into MS Project (shudder) to get a better breakdown.
  • No keyword expansion. This ruffled more than a few feathers as evidenced here. I've never used the feature in Source Safe, but to those who have used it, it is a sorely missed feature.
  • No sharing of files. This one is a bit annoying. While I've only used sharing sparingly, it's a very handy feature when you need it.
  • No shadow folder support. Once again, I've never used this feature. However, if you've depended on it - you'll miss it.
There are some notable differences for people that are used to Source Safe, such as:
  • TFS keeps track of everything in a Workspace. You have to get all the files that you want to work on before you can do anything. Also, if you don't check out a file in TFS, but you just make it writable, it will likely get overwritten because TFS didn't know that you wanted to do that. This causes all sorts of consternation for long time users of Source Safe. Martin Woodward does a good job of explaining Workspaces here.
  • Compares work a bit differently. In Source Safe, if you do a compare of a directory, SS will literally compare every file byte for byte and report any differences (which could take an eternity). On the other hand, TFS assumes that if you haven't checked out a particular file, it isn't different. That's how TFS operates so quickly. Most of the time it works the way you want, but once again, it's different than how it worked in SS.
I'm sure that there are many more pros, cons and differences, but those are the big ones IMHO / experience. Whatever Source Control solution you end up picking, make sure that you trial it to make sure that you can live with it. Once you have a bunch of data in the source control database, it's usually non-trivial to move it to another server.

No comments: