My Take on TFS

So, for the past couple of months at work, I’ve been living in Microsoft land doing SharePoint /ASP .NET web development. Now I’m not some blind Linux evangelist bemoaning the fact that I’m tethered to a large Microsoft stack during the daytime. In fact, I quite like the Microsoft languages and development resources and have always found them to be top-notch (MSDN documentation excluded). That was until I came across TFS (Team Foundation Server) which we use at work. Now I’m sure that TFS is all very fine for project and release management, but it’s an absolute train-wreck for version control… and as such, I cannot fathom how it managed to be coupled with such a great IDE as Visual Studio.

Where better to start than TFS’ archaic checkout model which insists that you check out a file with the server before you can edit it? It implements this in a very primal fashion by adding a read-only attribute to all versioned files and removing it when checking out. This means you need to manually check out a file in Visual Studio before attempting to alter it using an external tool (heaven forbid you should want to use anything outside VS!). Furthermore, if you manually remove the read-only attribute yourself and edit it outside VS, TFS won’t pick up your pending changes come commit time (and this does make me wonder how it would handle being cut off from a TFS server in a disconnected/offline scenario – I haven’t tried). I really don’t understand what’s wrong with the idea of scanning for file changes like most other version control tools? But the best part comes when you go to check in your files, only to be confronted with a slew of files which you’ve checked out at some stage but haven’t actually modified. If you compare with latest, TFS will tell you that the files are identical. Gee, thanks TFS! EDIT: I’ve since posted a workaround for this here.

Another thing I love about TFS is when it gets into a state where “Get Latest” doesn’t actually get the latest. Or rather, TFS appears to update to the latest revision and presents you with the latest files in Team Explorer, but miraculously, your local files in Solution Explorer are completely outdated. This is a consequence of its centralised model where the server basically says “My files haven’t changed since your system last grabbed them so I’m not going to give them to you”… well, it’s a bit annoying when it gets that wrong. The workaround is to select Get Specific Version and force an overwrite.

TFS seems to have its share of niggling usability issues. Why is it that right clicking a file and selecting Undo sometimes undoes the pending changes for that file, and sometimes brings up a new window allowing you to undo pending changes over multiple files? And why can’t I simply right click a file and undo pending changes? Half of the motive for using TFS is that it’s (meant to be) fully integrated with VS… so when you View History for a solution in Solution Explorer, shouldn’t it present you with the pending changes for all files in the solution rather than the changes for the specific VS .sln file which is almost never what a dev is after?

And don’t even get me started on the default merge tool. When I first started, a few of my colleagues did warn me to avoid it, expressing the opinion that it was downright dangerous. So after trying it and confirming that for myself, the very next thing I did was download WinMerge and use that instead.

I realise that I’m only scratching the surface of TFS, but I really hope I find something to like about it because at the moment, I’d happily swap it for command line SVN.

This entry was posted in Version Control and tagged , , , , , , . Bookmark the permalink.

1 Response to My Take on TFS

Leave a Reply

Your email address will not be published. Required fields are marked *