Review: Team Foundation Server

Until a few months or so ago, the policy where I worked was to use Microsoft’s Visual Source Safe (VSS) for source control. Now, granted, VSS does have something of a reputation for corrupting your repository, which is generally considered to be an unforgivable sin for a source control system. That, however, never happened to me, and VSS wasn’t particularly unusable. However, my current employer has started using Microsoft’s newer source control system, Team Foundation Server (TFS), which, I can honestly say is the first source control system to ever make me wish desperately for the sweet release of a corrupted repository.

Many issues are related to the plugin, which crashes my development environment several times each day, and takes agonisingly long to do anything successfully (I have time to read the newspaper while waiting for my code to finish checking in. When checking in doesn’t cause it to crash). But, still…

Getting code out of the repository can be a problem. Sometimes, I only get the solution file and the directory structure (but no code files). Other times, I get the code, except for a handful of (as near as I can tell) random files which have been left behind. Granted, on rare occasions, I am able to retrieve the files I need.

Some more complex operations can get a little hairier. For example, I once spent the best part of a day fighting against TFS with the unreasonable goal of moving a folder. A colleague has been trying to set up daily builds, and TFS seems to have a peculiar habit of using old versions of some files for no apparent reason. Other files are unaccountably missing for the use of these builds.

There are random “features” a-plenty too. One time I deleted a project (from my local computer) that had a few changes, after which checking that project out from TFS it would come, but not have any source control bindings. I don’t think I ever bothered trying to deal with that; luckily, I didn’t need that project any more.

TFS takes the VSS’ working paths to stupid extremes with workspaces, creating a system that behaves according to a hierarchy of configuration-heavy and hard to determine rules. Certain actions, like retrieving a project you haven’t accessed before, can alter your workspace configurations without troubling to let you know about it. And why have workspaces in the first place? I’m yet to see any useful feature they add that wasn’t done better by, say, Subversion, a usable source control system, without an unmanageable mess of configuration and a nightmarish cacophony of bugs (in some situations, for example, which I have yet to isolate, it doesn’t put a project into the workspace it is logically supposed to go to, but place them… somewhere else, typically Visual Studio’s projects folder).

Over the last few months, every single developer on our team has spent at least a week fighting against TFS. That said, TFS has its advantages – for example, it’s quite possibly useful as a treatment for hypotension. Unfortunately, I can’t think of any others at the moment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s