TFS is destroying your development capacity
derekhammer.com
derekhammer.com
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.
TFS is a worse source control system than CSV? That is bad! ;)
But yeah, I wouldn't be surprised if there was someone somewhere who had a pile of CSV-based shell scripts that outperformed TFS.
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.
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.
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.
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.
> 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:
http://msdn.microsoft.com/en-us/library/f9yw4ea0.aspx
tf add itemspec [/lock:(none|checkin|checkout)] [/type:filetype] [/noprompt] [/recursive] [/login:username,[password]]
...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 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.
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.
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.
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.
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.
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.