I can proudly say, that July is a successful month for me and my company. I've managed to plan and process a migration of our repository from hated Team Foundation Server 2010 into Mercurial! This change is quite spectacular because of differences in how repository works in Mercurial and TFS and also, there is need to change programmers' habits inherited from using Microsoft's SCM software. However, for now, migration looks quite successful. In the beginning I was quite doubtful about using a distributed revision control system and I was kinda not sure if merging won't cause any troubles, but it passed few simple exams and it worked as in a dream :) Below I will provide reasons why we needed to migrate from TFS to anything else and in the next part (in the near future) there will be informations about configuring the central code repository on Windows Server 2008 R2 and few guidance notes about using TortoiseHG and VisualHG in a every-day work.
Why TFS sucks?
Under that title one can manage to write a very long book, because this topic is so wide ;] In a nutshell Microsoft doesn't know anything about writing software (at least the branch responsible for TFS' development) and because of that using that piece of software is really frustrating and irritating. However, I must point that, you can learn to become a more patient and calm person (but sometimes you can become rather crazy, especially when the deadline is close and all what slows you down are your IDE and your revision control system). Below there are few more cons, which are significant for me and my coworkers:
- Extremely slow. There is a long response time for almost every action you can take (my personal record for start first edit: 6min and 35sec, also: adding file to solution, getting the latest version, making a shelve or discarding changes, etc.). By the way there is a curious citation about that found on Fowl Coder's site about pros of new version of Team Foundation Server: "It's fast as hell, at least compared to Source Safe. It's designed to run over a WAN and it communicates with the server via web services. Getting latest is very efficient because TFS only gives you what you need and doesn't need to check every file in your solution.". I can't even imagine how the Source Safe was slow then...
- Check-in check-out system. It's a solution for avoid generating conflicts by allowing to edit file to only one person (first person, who started edited it). Others are unable to edit that file unless owner unlock or commit file. Personally, I think it's really pain in the ass, because it's very limitative for programmer. However many people actually finds it as the most useful and helpful feature in the Team Foundation Server. This feature is also a performance killer, because on every action SCM need to contact with the central repository to find the actual state of a given file and - if necessary - change it in database.
- Blocking files on your hard disk. This is the most inconvenient con, especially for programmers, which use not only Visual Studio at the same time. The truth is, also VS isn't the very good software and some actions are really troublesome in this IDE (for example editing ResX files or more complex text processing). There are much better tools for these situations like a very good Simple ResX Editor or Sublime Text 2 (amazing text editor for programmers), but TFS very effectively disturbs even that. All files under TFS SCM are generally blocked (unless you check out them), and by blocked I mean set file to the read only mode in a file properties, so you cannot simply start edit file. But that's not all! If you manually change the file mode to read write, TFS will start ignoring this file.
- After installing TFS client, there is no Windows Shell extension for managing repository from Explorer (like in all Tortoise-like software), but - of course - you can manually download and install missing functionality. It's just a 300MB file.
- Merge and diff tools are really bad (and yes, there are sometimes situations when you need to merge files, even in the TFS)
- Expensive. Team Foundation Server costs $499, but IT companies doesn't usually pay for it, because they have MSDN Subscription which contains TFS, but it's still not so cheap because you need to have dedicated server with Windows Server 2003 (at least) and maintain it. There are of course on-line solutions for external storing TFS repositories, but also in this case it's very costly. For example (first found page) sample price is $109.99 per user per month. Comparing to other SCM: BitBucket in unlimited plan costs $80 per month and you can have as many users as you can imagine. You can see the difference.
- Creating and restoring a backup. Your server with TFS got down. What do you need to do? You have to find the last disk image and restore it to have the working and configured system (if you don't have that image, you are in a big trouble), and after that you need to restore the database with the repository and you have the server up again. I'm wondering - how long it will take in the real world? :> In the meantime all programmers in your team were unable to do anything. Failure of central repository in case of a distributed source control system isn't a very big problem, because - firstly - your programmers aren't blocked and still can do their work, commit changes, and generally use the repository, and - secondly - for collaboration in the meantime there can be used a different repository as the 'central' one. Moreover creating and restoring a backup is easier and quicker, because there is just a one directory with all repository data (with no database).
- And last, but not least: there are a lot of problems and questionable solutions applied to the repository management, which stop working just when we need them most. I was also wondering why you need to configure some workspace after you've just gotten the latest version of solution on your hard disk or why you can't have the solution from TFS stored in two different places (I have found this issue when I was migrating repository by the special tool). Probably someone could answer these questions, but - still - why trammel something, which works great in almost every SCM?
Why was TFS already used then?
There are also some pros, which are worth remembering (and which weren't so important for our team):
- TFS is a better solution for bigger teams, which are using not only Team Foundation Server source control system but also other tools like integrated project management, task management, reporting and automated build system. In our team these features weren't used, so - generally - the idea of using TFS was at least questionable.
- Because it was. It's kinda sad, but since TFS was in the MSDN subscription and this subscription was already paid, then why don't use it in company's projects? Hey, all .NET teams are doing it, so it has to be a good tool. Yeah, sure.
- Good integration with Visual Studio, however I would name it: ‘works with Visual Studio’. Moreover there is no need for additional configuration after install to start working with the repository (both on a client and server side). For example - to start using Mercurial on Windows you need to configure few things (both on a client and server side).
- Check-in check-out system as a way of avoid conflicts. In less experienced teams it's better to forbid the possibility of creating conflicts, than to allow to solve them by yourself.
In the next part of this article I will provide few informations about configuring the central repository, migrating repository from TFS, configuring client and more...