My rant about Team Server Foundation

Many developpers all tied together in an endless loop by Jonathan Caves

Many developers all tied together in an endless loop by Jonathan Caves

This is my first rant and it is probably not the last one.

Team Server Foundation (TFS) is the Microsoft way of managing source and doing some project tracking at the same time. It integrate so many Microsoft technologies that you are totally tied to one of Bill Gates’ leg when you are using it.

Let’s get started with the good ones. TFS is not such a bad software. It is at least five time much better than what was previously offered by Microsoft in the same field which was Visual Source Safe. It is well integrated with one of the most used IDE which is Visual Studio.

I have to use TFS on a daily basis mainly through the Visual Studio Team System (VSTS) which is the add-on for Visual Studio to access TFS. Getting used to it was a challenge since I tasted flexible, ligthweight and fully distributed source control management system before. I am still trying to figure out some of the details, but I am slowly merging with the Borg. Here is what I dislike about TFS.

You have to “Check out” a file before modifying it

After getting the source code of your application, before modifying any file, you have to perform a “Check out” to edit a file. Why ? Well, that is a good question. It might be to keep up with the good old fashion of doing things with Visual Source Safe. It might be to inform the central server of who is working on the file. It might be to disable developers from modifying a file that has been locked. I should probably not mention that you can remove the read-only attribute of the file to start messing up with this scheme.

The whole concept of “Check out” is my biggest complain about TFS and it is useless to say the least.

It is centrally based

Source control management should not be centrally based anymore. This is 2008 and the first distributed version control system was created in 1997. There is no reason to be tied to a central server and be locked out during shortages.

A developer should be able to work with his local repository the way he wants without being tied to a central server.

It uses weird concepts like shelves

Shelves is one of those things that are only really useful in some really specific situations. In my opinion, it should not have been implemented in the first place or only as an optional add-on. A shelve in TFS is a group of files that is stored in a temporary place with a given name. It is like a lightweight branch where you can easily share modifications that you did for approval by others for instance without having to create a branch for it.

The problem with this concept is that it is not a branch. You are actually storing files on the TFS server and not changes. When you are recovering those shelves or you are “unshelving” them, you are restoring those files and not the changes you made. If one of your colleagues modified that file while it was sitting on the server, you have to apply your colleagues changes to the file you retored before checking in that file. It is a real mess and quite error prone.

Merging is not trivial

I had to do my first merge between branches today. I must say that it was quite painful. After making Visual Studio crashed twice in a row, I resorted to use the command line client. It took me a while just to find out where it was. I had to read some online documentation to figure it all out because there is no command line help. Trying to get help from the command line will actually launch a windows help file.

After my first failed try, I forgot to specify the recursive switch. While waiting for my second failed try to complete, I search the blogsphere for some concrete examples. I figured out I had to specified a changeset range instead of just the changeset I wanted. Finally, I succeeded but it took a while even when I had the right command.

When you are finally doing the merge, it shows a bunch of windows specifying which files need to get merged without mentioning if there are any conflicting merges or if it can all be done without your intervention.

It is trying to do too many things at the same time

TFS is a you-will-not-need-any-other-tool-to-manage-your-project kind of application. It is trying to be a source control management software, a bug tracking software, a collaborative application, a reporting server, a continuous integration server, a portal server and some others. At best, it is succeeding in only one or two of those areas.

If you do not know anything else, it is probably the best thing in the world. Once you tried a few specialized tools in each of those aspects, you might stop relying on it.

It is not bundled with what you expect from a VCS

I expect my version control system to be bundled at least with a blame or annotate tool to find out who wrote which line in a file. You will not find this in the normal client package for TFS. You will need to install the power tools for TFS. Not to mention that in order to install the power tools, I had to install a bunch of other packages that all refused to install before I had install some other prerequisites.

My suggestion is to stay away from this monster.

Comments 2

  1. neongreen wrote:

    Hi!
    I was just wondering…how much time did it take you to learn or get accustomed to using Team Server Foundation….I am asking cause I have not worked with it so far…but my boss told me I would have to start using it soon…so that’s why I am asking….Thx in advance!

    Posted 29 Nov 2008 at 12:16 pm
  2. Rémy Roy wrote:

    Hello neongreen,

    Getting used to the basic Get Latest, Check Out, Check In is quick. It is probably a matter of minutes. If you happen to have a conflit, the conflit resolution workflow can take a little while to get used too.

    If you have to use Work Items in the process, that takes a few hours if you have to use all the panels.

    I hope it helps.

    Posted 30 Nov 2008 at 5:28 pm

Post a Comment

Your email is never published nor shared. Required fields are marked *

CAPTCHA image