TFS is destroying your development capacity

I have significant experience with CSV, SVN, Perforce, Source Depot (Microsoft's internal Perforce fork), Team Foundation Server, Mercurial, and Git. Roughly in that order of exposure.<p>I safely say that TFS is easily the slowest, least scriptable, most confusing, obnoxious piece of crap software that I have ever had the displeasure of using. The Microsoft-internal hate for TFS was astonishing, but political pressures forced us to use "dogfood" it.<p>Personally, I used to keep all of my source code at Microsoft in a local Mercurial repository (this was before Git had decent Windows support). I only interacted with TFS when I absolutely had to.

TFS truly is awful.<p>I am amazed that the cost is not mentioned in the article though.<p>Forced to use it where I work, because management wanted the reporting capabilities that it provides and like the turnkey solution. My back of napkin calculations came up with that for the cost of TFS we could have kept our existing SVN/Jira/CruiseControl solution (or migrated to a hosted solution) and hired someone at 60k a year to just write reports for the existing system, or paid Atlassian to come up with them for us.<p>Add in everything mentioned in the article, the cost and that basic functionality such as "get latest" doesn't and you have an impedance to developer productivity.<p>These days I tend get the TFS code, check into mercurial/git and work that way.

&#62; TFVC is a centralized-server model that requires constant and active communication between a client (read: developer) machine and the server. If, for example, the network goes down for 1 hour, development grinds to a halt. The reason here is that TFS will mark all files as read-only on the filesystem until you have asked the server to check them out for you.<p>Perforce works the same way, causing much frustration for me whenever I have to work with a slow and unreliable p4 server (and, despite Perforce marketing, those exist). You can override p4 and make writable the files you want to edit without telling the server. But when you want to check in a changeset, you have to tell the server you edited the files, otherwise they will get left out of the changeset. Worse yet, if you try to get too clever with your local copy's settings, the p4 utility might overwrite your changes with a newly checked-in version the next time you update your local copy.<p>When I worked at Microsoft in the early part of the last decade, we used a Perforce fork called Source Depot. (Internet mentions of sd are rare, but here is one: <a href="http://stackoverflow.com/questions/491295" rel="nofollow">http://stackoverflow.com/questions/491295</a>). I have no experience with TFS version control, but it looks to have taken a lot of inspiration from sd, which was a fresh breath after the previous revision control tool which didn't even support branches.

I'm sure there are lots of frustrating things in daily TFS workflow but some points in the article are quite wrong.<p>&#62; TFVC is a centralized-server model that requires constant and active communication between a client (read: developer) machine and the server. If, for example, the network goes down for 1 hour, development grinds to a halt. The reason here is that TFS will mark all files as read-only on the file system until you have asked the server to check them out for you.<p>You can switch to offline mode, and it will sync when you're reconnecting to the server.<p>&#62; TFVC wants you to do everything inside of Visual Studio.<p>Yes, but it's easily extendable, and there's a power tool integrating Tortoise like functionality to Explorer Shell. And there's always the command line tool, here's the syntax for "add", for example:<p><a href="http://msdn.microsoft.com/en-us/library/f9yw4ea0.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/f9yw4ea0.aspx</a><p><pre><code> tf add itemspec [/lock:(none|checkin|checkout)] [/type:filetype] [/noprompt] [/recursive] [/login:username,[password]] </code></pre> &#62; In order to create this bug work item, you need to use either Team Explorer (through Visual Studio, most likely) or the TFS 2010 Web Interface. The obvious problem for the first scenario is that developers are the only ones likely to have Visual Studio and are only one of several groups of people that could log a bug<p>...and Excel and MS Project, by default. Web + Excel + MS Project should cover almost all "several groups of people". And there's always this api, available through libraries or web services.<p>&#62; TFS as Agile Project Management ...<p>All project and work item templates are customizable, either via XML definitions or through a power tools interface. And when you do, all the external interfaces display your customizations without any additional work, be it Excel or TFS Web Access or the others. And they're instantly reportable too.<p>&#62; TFS as Build System ...<p>It can build MSBuild scripts, Ant and Maven builds natively. Constructing builds is always hard, MSBuild or workflow style build introduced in 2010 are no different. Normally, any sln file governing the project can be built without any modifications. I find gated check-ins or nightly builds quite easy to setup, his mileage seams varying.

I initially read this as "Team Fortress is ruining your development capacity." and I agree. I play too many games.

Obligatory link to git-tfs: <a href="https://github.com/spraints/git-tfs" rel="nofollow">https://github.com/spraints/git-tfs</a>

When set up and used properly, TFS is a decent source control / bug tracking system, especially if you use Visual Studio for day to day development.<p>The problems with TFS come from a few areas. First, it's easy to set it up in some sub-optimal configuration, by putting it on insufficient hardware, for example. There's a very real and very high cost to doing that aspect right, of course. Second, if you're doing development with a small team and a limited number of branches, TFS is probably overkill, and the way the tradeoffs are balanced for TFS is probably way off from the actual tradeoffs your team needs. Third, if writing code in the VS IDE isn't the norm then you might be going against the TFS grain enough to cause serious pain. Fourth, if you don't use the bug/work item tracking parts of TFS then it'll have less value to you, obviously.<p>Finally, the biggest problem with TFS is the competition. People apply the label "distributed version control systems" to Mercurial and Git but that hides the important aspect that these systems are not <i>just</i> capable of decentralization but they are also extremely fully featured and highly advanced modern VCSes. If you are deciding ab initio which VCS to use it'd be silly to not choose Hg or Git for almost any project. They are free, there is tons of support, they are scalable, and they are extremely good.

Can't really recognize these problems. I've no problem with working offline for example. You get the latest version from the repository, do your stuff and check-in when your done. Conflicts are pretty easy too. I don't know this 3 pane "standard" merge view that the guy is ranting about, but the 2 pane (local and remote version) view in TFS works just fine for me.<p>Bug and work items, sure, not very good. Usable, but still prefer to keep issue tracking outside TFS.<p>I've only used SVN apart from TFS, and while it does the job, I mainly used it because it's free. Really disliked the hidden .svn files cluttering up folders though.<p>I've never really gotten Git or Mercurial. They seem to be for linux command-line type of coders. But I really wouldn't know, as I haven't used them.<p>TFS works just fine. If you are doing MS development, it's probably the best tool for the job.<p>The majority of these kinds of rants come from people who are used to something else, then proceed to proclaim certain software "stupid", because it does not work like their favorite choice of similar software.<p>A bit silly really - Use what you like, but don't engage in bouts of mud throwing. You'll just be as much of a "factionist" as the author implicitly claims he is not.

Although I agree with the overall sentiment, there are a few inaccuracies with this article. I am not defending TFS, just correcting.<p>To address the point about losing connectivity, VS prompts you to "Go offline" which removes all the readonly flags from every file and folder (I know...) and does a folder scan like a regular basic VCC would do upon reconnection. I haven't had a problem with this (as long as your copy is very close to the server copy).<p>To address the point about multiple merges, you can select multiple conflicts and perform bulk operations on them (accept server, accept client etc) and I'm pretty sure automerge is one of the options.<p>Also yes the merging tool is horrendous. I use p4merge instead for both TFS and git. Much easier to see what has changed and also easier to cherry pick.

My understanding of TFS is that the only reason it exists is to sell more SQL Server licenses.

Agree entirely with the article.<p>TFS is one of those products that you feel like you should be using what with being an ENTERPRISE, but after a couple of stand-offs with it, you feel like you've been thoroughly well and truly raped by the vendor. This is unless you were using VSS before at which point you are scarred for life.<p>I made a fair bit of cash between '03-'07 saving people from botched, painful VSS and TFS environments. If people pay you lots of money and worship the ground you walk on for getting rid of TFS, then it's probably a bad product.<p>I replaced them with a simple scripted virtual Debian/Trac/SVN appliance with Active Directory integration via LDAP. I let them design and build their own processes and workflows with Trac workflow. I do the same but with Trac and Mercurial now.