Microsoft Team Foundation Server vs Git

For the last few weeks, and in the coming months, I’ve had to (and will have to) work with Microsoft’s Team Foundation Server (TFS).

I have a habit of working on more than one thing at the same time – call it sustained partial attention or multi-tasking, but I try to optimize the use of my time. E.g. when my computer is compiling one project, I can usually work on another project while it’s doing that: as long as I have stuff to do, I can keep working even if my computer is working on other stuff. There is a limit to the number of projects I can work on in parallel, however, just like there’s a limit to the amount of (real) work the computer can do in parallel. My limit is usually lower than the computer’s limit: computers do unintelligent things really fast while humans (such as myself) do intelligent things really slowly. That means that by the time I have another “dumb job” for the computer, it’s usually finished the one I gave it earlier so I can pick up where I left off. That way, I don’t spend too much time waiting for my computer.

That whole idea is out the window when using TFS: ever since I stopped using CVS a few years ago, I had stopped waiting for my computer for any significant amount of time – but now, those days are back with a vengeance!

Though TFS has a very convenient user interface that integrates very nicely with Microsoft’s Visual Studio, and it does have a few features CVS and Subversion don’t, it is also a huge waste of time. It takes seconds – nay minutes – to create a branch (which, for some reason, you then have to check in which takes another eternity) and it is impossible to take a changeset from one branch and apply it to another (cherry-picking) unless the two happen to have a parent-child relationship.

As TFS is a centralized system, it has to talk to the server for everything you might want to do, which includes creating branches, merging, checking in/out, etc.

I had never realized how utterly brain-dead that really is! If there is any load on the server – which there is bound to be if you’re working with a fairly large development team – TFS slows down to a crawl.

The one operation that takes any significant amount of time using Git is the clone operation: it downloads everything, includes all of the history. Clones a large project may take a while but once that’s done, pushing and pulling, the one other more or less daily operations that take any time, are still pretty fast. Anything else is done locally, making it all blindingly fast – even on Windows, with both Windows and Cygwin slowing things down.

With TFS, even checking out a small project seems to take an eternity compared to this.

The silver lining? Every time I try to do something with TFS, I end up loving Git more than I did before!

About rlc

Software Analyst in embedded systems and C++, C and VHDL developer, I specialize in security, communications protocols and time synchronization, and am interested in concurrency, generic meta-programming and functional programming and their practical applications. I take a pragmatic approach to project management, focusing on the management of risk and scope. I have over two decades of experience as a software professional and a background in science.
This entry was posted in Opinions, Software Development, Technology. Bookmark the permalink.

7 Responses to Microsoft Team Foundation Server vs Git

  1. Matt says:

    Hi there,

    I wanted to chime in on a few points you made:

    TFS Branching being slow – this is a common complaint we had from users, and we’ve made a significant amount of changes in TFS 2010. Branches are now entirely created on the server, so no more pending locally just to send back to the server. So, instead of 2 round trips for each item on the branch, we have 1 call for the entire branch (and a Get you’ll need to do if you want to have the items locally).

    Cherry pick merges – TFS does allow you to merge between branches without relationships, but only via the command line (tf merge /baseless). In TFS 2010, if you’ve done the baseless merge once from the command line, then you’ll see the merge target in the UI for subsequent merges.

    Hope that helps,
    Matt

  2. Samuel Tremblay says:

    Don’t know if it help him but it helped me a lot

    thanks!

  3. Pingback: Distributed Software Development Part 3: Tools Of The Trade @ Making Life Easier

  4. Dr J says:

    Hi

    I have been using TFS for a many years and I think it is an excellent tool, if you are developing using Microsoft technologies.

    Also you need to understand TFS is an ALM tool, not just a source control system. I have been using the work item tracking for a long time and it is great. In order to accomplish similar capabilities you need to go thru integrating different products

    • rlc says:

      Hi Dr J,

      I’ve been working with TFS for the past few years now, using Microsoft tools working on Windows-based (and CE-based) software and firmware and while I agree that TFS brings a few things to change control that Git does not (as you said: TFS is an ALM tool whereas Git is an SCM tool) I haven’t really changed my opinion about it.

      The fact that it’s not distributed — which it’s SCM side certainly could be, even if its integrated SharePoint, work items, etc. can’t — and the fact that it hogs enormous amounts of resources for doing the most trivial things not only annoys me, but has had a real impact on my measurable productivity. The amount of time spent waiting for my computer is only partly mitigated by the fact that I have more than one computer to work with.

      The overhead associated with simple tasks such as creating a branch, which takes several steps each of which takes precious time, or committing code, which also takes a lot more time than it would seem to need to take, has actually introduced some arguably bad habits into my normal routines. For example, I don’t check my code in nearly as often as I used to, relying on automated backups of my workspace to prevent loss of code. That means that when I do commit my code, commits are a lot bigger than the ones I would make for equivalent work using Git.

      Unlike Git, TFS doesn’t have an interactive “add” command, allowing you to stage partial changes, so if I wanted to splt my commits up into smaller chunks (which also happens when I’m working with Git, but which has become more frequent working with Git since I started working with TFS due to the bad habits I picked up working with TFS) I would have to use TFS’s “shelve” feature to do the equivalent.

      I could go on for a while, but I’ll make the opposite argument in stead: I recently introduced one of my TFS-using colleagues to Git (he needed access to some code from Vlinder Software, and we (Vlinder) use Git for versioning). He installed the Tortoise plug-in for Windows explorer and got the hang of using Git quite quickly — and he was enamored by its elegance and speed. At some point, he’d probably be able to lose some of those bad habits I mentioned and pick up the “commit early, commit often” mantra…

      Anyway, I rue the day I started using TFS and will one day either convince my TFS-using colleagues to see the light and use Git or some equivalent (I could live with Hg, for example), or leave the central-server-oriented world behind and return full-time to the freedom and speed of distributed versioning and content-addressable file systems.

      OTOH, I’d be more than willing to read about what you like about the bane of SCMs (which, granted, isn’t a bad ALM at all — just a bad SCM).

      Thanks!

  5. Mark says:

    I just wanted to throw my $.02 in as a sys admin. My background is more in linux servers than Windows, but I’m no stranger to Windows Server environments either, having set up several Active Directory & IIS servers. And I just want to say that I have never been more horrified and shocked than by the steps that I had to take to get SQL Server/TFS with Sharepoint integration installed. Complete piece of junk. And stability has also been a huge problem. As you’ve mentioned, TFS hogs massive amounts of resources for the most trivial of tasks–At boot (yes it has to be regularly rebooted), the system is taking up 5GB of RAM, most of it by SQL Server. Within a day of use by 6 developers, it blossoms out to 10GB of RAM used. They’re just checking in code! I’ve got a CentOS-based SVN box doing more or less the same thing (minus the ALM), and it runs just fine on 1GB of RAM.

    There is something seriously wrong with TFS, and while I get the allure of the integration it provides, even the users who haven’t seen the blood, sweat, & tears (of anger & frustration) that have gone into just getting TFS up and running, they still have plenty of issues themselves just using it. So I don’t get why people hold it up to some kind of gold standard.

Comments are closed.