Why I dislike TFS - Team Foundation Server
I don't usually blog about subjective things like my likes and dislikes, and I usually like (some will say I am in love with) Microsoft, but TFS is just horrible.
Here is a list of why I don't like it, in no particular order:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Server isn't free -- 'Nuff said.
I'm sure there are other problems but this is all I could think of while writing this.
Sure there are some nice things about TFS, but honestly the cons far outweigh the pros. So if you have to decide which SCM to use and you run across this blog I think it's pretty obvious that I don't recommend it. I love SVN and as GIT (tools) mature I'm sure I will switch to that.
17 Comments
Leave a comment
0 TrackBacks
Listed below are links to blogs that reference this entry: Why I dislike TFS - Team Foundation Server.
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/628
Read-only files
- TFS is a Visual Studio plugin. Not a file system centric source control product like subversion etc.
Identical Files
- Agreed, a pain, but you can select all pending changes, click undo changes, it then has a prompt in which you can choose not to undo on files that have actually changed.
Code reviews
- You can on the Project do a View History which shows all changes in a given changeset, not on a per file basis.
Deleted files
- Files that are not in the solution but still in situ on the drive can be seen across a project by clicking the Show all files option on the solution explorer.
Project file modification
- Agreed this can be a problem, the easiest solution for this is for your VPN workers to right click the file (in file explorer) and uncheck read only, then edit the file's connectionstring.
This way it won't be checked it (unless other file changes are made).
Integrating with non .NET developers
- Agreed, not handy.
Working offline
- The work offline option of TFS doesn't require you to hit the server. If it can't initially detect the server, it'll prompt you for offline mode. No further issues, checkin tends to be straight forward too.
I love TFS, SVN has always been a thorn when I've used it. The merging process can be nicer but that's the only benefit I've seen so far.
GIT I've yet to try, from SourceSafe to TFS was such a huge improvement including build on checkin etc that I find it hard to agree on most of your points.
I dissagree with some of your points.
Identical Files - I'm not sure what you're talking about: A file won't get cehcked-in if it doesn't contain any changes.
Code reviews/update - You can easily achieve this, by right-clickinmg in a code-window, and going source-control/annotate.
Project file modification - This would be a complete pain in SVN too (I'm pretty sure) - you could always have two project files - one for each server. (this would need maintaining, in the case of changes to the solution structure)
Everything needs to be in the solution - Wrong. You can add add-hoc files from source control explorer, by clicking the "add files" button.
I've used both SVN and TFS quite extensivly - and find that in general, TFS & VS are wonderful tools - although not without their faults. I find during day-to day usage of SNV - that my source-tree breaks for no-reason all the time. I get "unresolved conflicts" for no reason at all. It constantly tell me to "clean up" - and then the "clean up" crashes my computer.
Both products are imperfect - but at least Microsoft doesen't release updates every 10 minutes, like Tortoise do.
What about deleting a file, then adding a new one with the same one. I do this with JavaScript libraries some times and it's a complete nightmare.
I meant adding a new file with the same "name". Then all hell ensues when trying to merge...
I my couple of months of using TFS I can say I pretty much agree with you.
As for viewing a changeset without going to a file and viewing the history, the only way I found is via a command-line. You have to open a "Visual Studio Command Prompt" (unless you already added TFS to your path for the normal command prompt) and type: tf changeset [changeset #]
I don't entirely disagree, but it's important to mention that TFS is about more than source control. It integrates source control, work item tracking, defect tracking, and backlog management directly into Visual Studio. For organizations that want a turnkey solution, or that have policies against OSS, it can be very valuable.
As a remote worker I personally prefer SVN + Tortoise, with work item tracking handled outside the IDE, but I do miss the simplicity of TFS Shelvesets.
Full Disclosure: Hating TFS is a favorite pass time of mine.
TFS does indeed do more than just act as source control. In fact, it is like someone took the 5 worst tools they could find for source control (VSS excluded, of course,) testing, issue tracking, automated build and code analysis and put them all in one product! Yay!
Besides the whole, "Clicking the Get Latest menu item doesn't always update you to the most resent version of the code, so you ALWAYS have to force get latest to make sure you have what you need" issue, the real deal killer for me is MSTest. This is the slowest, most DDT (rather than TDD) tool I have every attempted to use. Waiting 8+ seconds for each test run to start completely kills the flow of TDD and makes test runs less and less common. Rather than helping our team embrace TDD, TFS makes TDD painful.
The CI components are a whole other (painful) story. Lets just leave it at, "they don't work for real code (like so many other demo-worthy Microsoft products.)"
Reverting a file is terrible in TFS.
http://msdn.microsoft.com/en-us/library/ms194956.aspx
11 steps. W...T...F...
@Seth. Agreed, but FogBugz does that other stuff and integrates well with Subversion. We've set it up so you specify the FB case number in SVN checkins, and get automatic linking between the case and the code changes. Also there's no "n" in "turkey" :)
" Everything needs to be in the solution "
actually you can build the directory structure using source control explorer so, that documentation files, script files (sql etc) can be outside the solution in their own directories.
@Ilja. You can, but from then on all "updates" need to be done from "Team Explorer" instead of "Solution Explorer" otherwise you won't see the updates.
I tend to agree with most of this. If all you're looking for is source control, and you also work with a lot of non-Microsoft file types or with Macs, TFS is not for you. It is good for MS-centric large organizations who need to track many development projects via integrated source control, automated builds, code coverage across the organization, work items, etc.
For the workspace issue -- I do think they're a bit annoying -- but if you need to check out multiple copies, one for bug fix, one for feature -- you should create a separate branch. The branching and merging in TFS is actually pretty decent.
You'll know you made a mistake using TFS as your SCC system the first time you get a 'Filename collision on server' error when checking in a merge.
Everything doesn't need to be in a solution. Using Team Explorer you can add files independent of a solution.
Scratch numbers 1 and 8 from this list. Change title to "11 Things I hate about TFS but I'm probably wrong about some of them".
Couldn't agree with you more! TFS is the worst version control system ever...I'd rather go back to CVS than TFS any day.
Did anyone ever try braching and merging with TFS in more complex branches?
It works like hell here with us...
The last 3 days I had to cope with TFS related misery items concerning branching and merging. Of those 300% working time I worked 230% on TFS bullshit.
Version Control systems are suposed to help you separate code in branches and keep them in sync. They don't supose to work against you !
Sorry for this rant, but I'm sick of TFS. I hope I'll never have to work with that product ever again.
Steve - I feel your pain. Using TFS is like trying to build a house with a hammer where the head keeps flying off. You spend 90% of your time battling the tool instead of getting real work done.