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.
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.
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.
How recent was your experience with TFS? It's been around for 6 years and shipped 3 versions, that should be enough time for it to be good enough for dogfood.
> I have significant experience with CSV, SVN, Perforce, Source Depot (Microsoft's internal Perforce fork), Team Foundation Server, Mercurial, and Git.
TFS is a worse source control system than CSV? That is bad! ;)
Oh man, I did the same when I was at Microsoft for a couple of months for an internship (although I had to interact with SD instead). Coming from hg I found SD to be pretty obnoxious. Thankfully my mentor was fine with it: "whatever works for you".
I am amazed that the cost is not mentioned in the article though.
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.
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.
These days I tend get the TFS code, check into mercurial/git and work that way.
> 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.
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.
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: http://stackoverflow.com/questions/491295). 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.
Editing of local files "behind the back" of the P4 server is not that bad. When you reconnect to the server, just ask your P4 client to "synchronize offline changes" (in P4V, I think) or just checkout your entire clientspec and ask your P4 client to revert unchanged files. I'm sure these operations could be easily scripted, too.
Clearly not ideal, but workable. I'm surprised Perforce has not created offline changelists (like git or Mercurial's Patch Queue). The feature could probably be implemented entirely in P4 client code. Perforce has implement server-assisted "shelving" of changelists, but I don't find that as helpful as local branches or changelists would be.
> When you reconnect to the server, just ask your P4 client to "synchronize offline changes" (in P4V, I think)... I'm sure these operations could be easily scripted, too.
p4v does have a lot of added features and conveniences. Maybe I'm an old fart, or maybe I'm just too used to sd (which didn't have an official GUI client app when I used it) but I don't actually like to use p4v, preferring to use the p4 command-line tool. So, yes, I've gotten used to automating certain operations via shell scripts that wrap p4.
> ... or just checkout your entire clientspec and ask your P4 client to revert unchanged files...
If you do that, though, the server will tell everyone else that checks out any file that you have it opened for edit too. This can be really misleading when they want to delete or integrate to the file. I don't like that Perforce implicitly discourages merging branches through "who else has opened this file" notifications, but that's how it is and I'd rather not abuse the system.
I'm sure there are lots of frustrating things in daily TFS workflow but some points in the article are quite wrong.
> 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.
You can switch to offline mode, and it will sync when you're reconnecting to the server.
> TFVC wants you to do everything inside of Visual Studio.
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:
> 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
...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.
> TFS as Agile Project Management
...
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.
> TFS as Build System
...
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.
The command line tool is much nicer than the GUI, but there is still no way to get easily machine parseable output. Unlike Git, all of the `tf` commands are porcelain. If you want plumbing, you need to code to the COM/C# APIs.
I can write an article on this topic. I rationalize the time wasted by playing as Engineer. I also work for a Gamification startup so I can call it 'research' :)
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.
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.
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 just 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.
Bug and work items, sure, not very good. Usable, but still prefer to keep issue tracking outside TFS.
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.
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.
TFS works just fine. If you are doing MS development, it's probably the best tool for the job.
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.
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.
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).
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.
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.
I've had to deal with this a few times. I make a brief mention of it in my article but gloss over the details because I wanted to get on to more important topics.
In general, offline mode has been a terrible experience for me. It is handled differently in different versions of TFS. In one version (2008?), you go to File -> Offline Mode. In another, you need to either reopen the solution and get prompted project by project to Temporarily Work Offline or unbind TFS manually.
In both solutions, I've had difficulty reconnecting to TFS. In a complex set of steps that were probably "dumb" but seemed like my only options, I have lost changes made on my local file system.
My experience may vary from others, granted. Though, after talking to some colleagues about their experience, mine has been easy.
Fair enough. I guess the overall impression we both share of the offline process can be summed up by the word "unintuitive".
Also funnily enough, I've just come back after lunch to find something has killed SQL Server, which has affected TFS, forcing me to experience all the joy that is offline mode. I'll no doubt be swearing and cursing MS in a few minutes.
Turns out I was wrong. It doesn't clear the read only flag. Just makes you overwrite the file. The scary thought is that TFS only recognises changes if the file is writable. Hopefully it does when our SQL machine comes back up. I shouldn't have to hope though.
It was more about getting the Developer Division to be a $1 billion in revenue department. My guess is that TFS is a drop in the bucket for SQL Server revenue.
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.
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.
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.
TFS is a below average source control system in an age when there are many better choices. VSS, on the other hand, is an active threat to all of your code.
At a previous employer, I was delighted by the switch to TFS, because it meant we no longer had to worry about the VSS file store getting corrupted and losing data. Now I'm on contract with another employer still using VSS, and we should be cutting over to TFS soon. Once again, I will be delighted. Because the below average is a welcome change from the flatly unacceptable.
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.
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.