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.
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-u...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.
Add to that list:Mysterious error messages, example "There is a merge conflict please resolve conflicts and try again" Ok, what file(s) are conflicted? Conflict list is showing no conflicts...WTF is with "Get latest" that doesn't get the latest?On #1 CodePlex now supports mercurial as an alternative to TFS.I've used SourceSafe, CVS, SVN, Mercurial and TFS over the years, to start a project now I would be using Mercurial. It has excellent merge and is very unobtrusive. TFS is little more than an "improved" SourceSafe (from a SCM perspective).
Switching from SVN to TFS was like a bad dream, a big step down. The only thing I found that might be better is the merging UI in TFS. A lot easier than merging using SVN (including w/ TortoiseSVN).The 2 times I made a branch off our trunk for some significant dev work, the merge back was absolutely horrific. I was very dilligent to merge any (and there weren't very many) changes in trunk to the branch. I did this multiple times daily. When I went to merge back I got all kinds of conflicts and God forbid you dare to rename or move a file in your branch.So after I resolved all those conflicts in the merge (this was very painful, btw) I thought I was out of the woods. Nothing could have been further from the truth. There were more conflicts on the checkin of the trunk post merge including filename collisions.On the filename collisions they gave you 2 and only 2 paths to resolve, both of which led to nowhere. Totally stuck.After suffering this same exact scenario twice, I can only conclude that TFS 2008 is a completely worthless piece of software for any semi-serious and above shop.Hopefully 2010 fixes all this, but I haven't seen anything. I have my doubts and I would not be using TFS had I not been forced to by our client.
Holy God in heaven, please spare us from the evil that is TFS source control. I'm totally serious. I hate TFS so bad that the bile rises in my throat just thinking about it.My favorites (sarcasm) are the "you just don't understand the tool" comments. YEAH NO KIDDING I DON'T UNDERSTAND THE TOOL, it's a TOTALLY RIDICULOUS PIECE OF GARBAGE.Just today I had to remove and restore source control bindings so that Visual Studio would pick up the changes to my solution file. WTF?!?!?!? When I check in, I expect it to ACTUALLY CHECK IN ALL MY CHANGED FILES.Further gripes:Add a binary file to your project. Shelf the project. Try to unshelf the project from another workspace. You can't, because the binary file is locked. OK, unlock it. Oh sorry, you CAN'T because it "must remain locked because its file type prevents multiple check-outs". So I can't share my project without checking it in? I DON'T WANT TO CHECK IT IN, WHICH IS WHY I USED A SHELFSET TO BEGIN WITH.In another workspace, Unshelve Pending Changes. Oops, there are local modifications. So Undo Pending Changes then. Now Unshelve again. FAILS DUE TO PENDING CHANGES. Which ones, the ones I JUST EFFING UNDID?!?!?! No, the undo affected the project file. Ok, Undo Pending and then Unshelve again. FAILS AGAIN because there are STILL PENDING CHANGES. Undo Pending again and finally the Unshelve succeeds. WTF!?!?!?In offline mode, try to rename a file. How interesting, the name silently reverts back to its original name, no error message. WTF!?!?!?Often have to Get Latest twice to actually GET LATEST.Abysmal awareness of offline file changes. Try to edit a file when offline that you hadn't checked out. Error message. Continue with the edit and save it. Now go online. "Searching for online changes…" finds… no changes. WHAT ABOUT THE FILE I JUST EDITED?The Solution Explorer window lies about the status of files in the solution. Files are "Checked in" or "Checked out by someone else or in another place" apparently randomly. I have the same solution in two workspaces (checked out with no locks) and the two solution trees show different files with the little person icon and the little lock icon with no apparent pattern or sense. WTF?!?!?!...Why couldn't Microsoft have stuck to what they do best, and bought out a nice little source control company, instead of rolling their own HORRIBLE RAGE-INDUCING JUNKWARE? I wish.I like the rest of Visual Studio though.
Fun times: just finished a feature, checked it in, everything says I got latest (Team Explorer and Solution Explorer). So I figure we're good to go for the QA release that will finally let the business users play with my new code. QA release goes out, but runs into an issue because the build server can't find a property I added to a code file. As it turns out, my latest wasn't so late after all. Force get, the property that I had on my local, supposedly current file disappears. Son of a bitch. Add the property, check it into dev and QA. Build goes out, but my changes don't. Turns out my other changes were not-quite-latest. So, from the point of view of my code, that's a QA build wasted, and when the builds are all done halfway across the world, we can't simply kick off another QA build. There's always tomorrow, I guess...tl;dr: TFS sucks. I googled "TFS sucks" just so I could vent and commiserate.
I remember using Clear Case and wondering how much more frustrating a SCC system could be. Well, wonder no longer, if you want to find out for yourself, try TFS. You'll yearn for Clear Case.
While I do not totally disagree that you may not be incorrect, I also think that the correctness with which you speak may not be totally wrong.
I've been using it for 6 months now, and I agree with all your points apart from 5 and 8.It seems like the TFS source control team made every design decision along the lines of "what is most like SourceSafe?", rather than what works best.The combination of requiring checkouts and making the server hold client state (rather than the SVN model of having local caches) kills not just performance, but also usability by requiring the stupid workspace model and readonly files. What does it save? A bit of client HDD space, big deal.There are just so many little speedbumps in the workflow it drives me mildly mad. I mean, SVN was far from perfect, but to actually make something so much worse is just crazy.
@Matt, I think you said it perfectly -why the hell does TFS hold client state!?But it's more than that... TFS attempts to do too much. It attempts source control, build-automation, and SCM. These are VERY separate concerns and I really dislike the build-automation as is. Think about how MSDeploy works independent of TFS. That's exactly how build-automation should work... independently of the darned source control!The same goes for the SCM stuff. It's not that the SCM of TFS is all that bad, but why isn't it seperate?
TFS is one of the worst tools I have worked. Git|SVN|CVS|Mercurial :)
I'm using TFS for a couple of months now and i agree with you on almost every point, and the other point i just don't care, size 200 or 15, with gigabytes to spare this is no problem, and the fact the server ain't free is not a big issue either. But damn, some people used the say TFS was heaven, a pleasure to work with, the end of my suffering... maybe i got a little too excited. Have worked with SourceSafe for years and a couple of years with SVN, but i wish they would give me SVN here or SourceSafe at least.... TFS... what a disappointment!
I dissagree with none of your points.
tfs is shit
Hi,I have to learn TFS .I dont understand BAscis of it why we use it.please Help me out.
I replied to your post with my comments. I understand quite a few of your complaints. Many of them have been resolved in the next version of TFS and Visual Studio and many others can be easily mitigated by installing a few add-ins for Visual Studio.Some of your points are just true. And I'm hoping Microsoft will fix them in due time.http://blog.jessehouwing.nl/20...
TFS only lets you work the way it wants you to work. SVN just does what you tell it. Recently I created a TFS workspace on a VM, made some changes, a support request came in so I reverted the VM to another snapshot, then I went back to the changes I was making. At this point TFS told me that I wasn't allowed to check anything in because I didn't have anything checked out, why does it constantly try to stop you doing things. With SVN you just say check this in over that, and it does it, without arguing and getting it wrong. If you think TFS is an acceptable software solution then you shouldn't be working in software, it's awful. If anyone working for me made any of the mistakes Microsoft make on a regular basis I would fire them immediately.
"Workspaces...If you want two copies of the same project checked out good luck because I can't figure it out."
Uhhh... That's exactly what workspaces let you do..."Project file modification...Since the solution file stores the connection string to TFS it's constantly getting checked in."
So the project file isn't being modified. The solution file is. Why are you checking in solution files?"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."
This one is just a lie."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."
Better question is "Why would you use TFS if you're not going to be using Visual Studio?" (by the way, it is Visual Studio, not Visual Studios). It makes everything read-only so that only the files you check out can have changes. Changing files locally that you haven't checked out just means you're going to forget which files you changed and TFS doesn't do a line by line comparison to see if you have the latest version from source control. It knows what version you did a "get" on and it knows what the current version is. If the version numbers are the same then you have latest.There are legit reasons why TFS sucks, but none of them are on this list.
I 100% agree with you. TFS sucks!
We are experiencing allot of problems on a daily basis.
Features that exists in other products for years doesn't not exists in TFS, to achieve the same result you need allot of customization.
Build Templates are not comfortable and very error prone.I have a huge list of problems with TFS and very little time to write about it...Git + TeamCity + YouTrack is the perfect match in my opinion.Don't waist you time on TFS.