TFS vs. Subversion fact check

I spotted a good comparison of TFS vs. Subversion by Jarosław Dobrzański on DZone (you can also read the original post) but I feel that a couple of the points were either out of date, or bourn out of a lack of knowledge of the product, or even more likely I just missed the point. This article was taken from the perspective of an SVN user who has moved to TFS, and I am not in that category.

---

I want to take a look at each of the “Weak points” mentioned and see if there is anything in them.

>>Subversion promotes a very clear view (similar to CVS) on the files tree on the server: trunk, branches, tags. In TFS everything is in one bag – branches are simple directories among the other content of ‘the trunk’. It still looks messy to me.

This was the case in versions prior to TFS 2010, but with the new branching features it is easy to both see where your branches are and what change sets have been merged to which branches.

Figure: Branches are easy to identify

If you have your branches setup as just directories in the trunk then it is probably the case that your company is just doing it wrong. You should have a standard layout as I have shown above, and indeed this is the format that is recommended in the TFS Branching Guidance and I would recommend that you read it before you just dive into branching.

>>If you want to edit a file you need to check it out for edit so that it’s listed in Pending Changes window after it’s changed. If you edit a file directly in Visual Studio it checks it out for edit automatically; however, if you make the changes outside Visual Studio (you need to change Read-only property prior to that) and forget to check it out for edit in Visual Studio the file is not listed in Pending Changes window. Consequently, the risk of not including that item while making a check-in increases (I personally experienced that a couple of times….)

Having never used SVN and having come from a Visual SourceSafe background I have not had this problem, but I have heard this from many other SVN users and I completely agree and understand the perspective. Although I find it difficult to understand how you know which files you have checked out when you don’t have this, it looks like all the source control products are going in this distributed direction and I will just have to go with the flow.

>>It’s dedicated to Windows platforms only, but this is hardly a problem for a team who uses Visual Studio.

This one is just plain wrong. I don’t blame the author, I would be much more inclined to blame the marketing team a Microsoft for not making this as big a deal as it should be. Can you say “Team Explorer Everywhere”.

This was originally a third party product called Teamprise that integrated Eclipse into TFS, but with its purchase by Microsoft and the launch of TFS 2010 they have beefed it up so that it supports:

• Apple Mac OS X
• HP-UX
• IBM AIX
• Linux
• Solaris
• Unix
• Windows

On top of that it also supports :

• Eclipse
• IBM Rational Application Developer
• Adobe Flex Builder
• Aptana Studio
• others

This is a massive move by Microsoft to increase the reach of TFS to other platforms, and with the TFS application model being completely service based more diverse support will be coming in the future.

>>Weak support for reverting changes

I don’t know if weak is the correct word, but yes it is difficult. It was designed to be difficult as you don’t want your developers thinking that it is OK to check-in crap because they can always revert it. I don’t know about you, but I do not want to ever have to revert a change. If I do, it shows a failing in a quality gate somewhere that needs fixed.

• Rollback Command (Team Foundation Version Control) (I need to rollback and entire change set)
• How to revert changes checked into TFS Version Control (I just need to rollback one file)

I like this being hard…

>>It’s not a free tool

This is really only partly true. Anyone with a MSDN subscription has a licence to both run a TFS server and to connect to any TFS instance, couple that with SQL Server Standard being included in the definition of a TFS Licence then you can pretty much run TFS for free. If you have some business users that do not have MSDN, then yes, you will need to buy some retail CAL’s, but with the retail TFS 2010 at £500 that includes 5 users without CAL’s price is not an excuse not to use TFS.

If you are an open source developer with no MSDN subscription then you can use Codeplex which is completely free from end to end.

>>Complex installation

This was VERY true in TFS 2005 and TFS 2008, but in TFS 2010 the installation is so easy my Dad could do it. I blogged about this during the beta and managed to install and configure TFS 2010 in under 30 minutes.

>>Lack of switching feature. With Subversion I could easily switch between trunk and branches / tags, still using the same source directory. The action was straightforward and quick. On TFS you need to make a full check out of the other branch, which is longer and requires additional actions (e.g. IIS settings for new virtual directories)

I can agree with this, but I also agree with the way that TFS does things. I do not want developers to be under any ambiguity of which branch they are working with, nor do I want them to be able to mistakenly check into the wrong branch.

I always run each branch separately on my local development computer and the minor setup of IIS or other stuff is really just that, minor.

>>Poor support for revert (roll back). It’s not that easy to revert a check in (especially if it includes lots of files). Official roll back instruction sounds like a workaround…

Having covered this already I don’t know why it is in here twice, but never mind. The official link above while for VS 2005 is a good solution for rolling back a single file. Remember that there is high fidelity between files checked in at the same time and a check-in becomes an atomic unit. If you want to rollback a single file, then this is the easiest and least painful way. There are methods for rolling back whole change sets, but again these are things you do not really want your developers doing.

I should also note that in my 3 years as an ALM MVP and 9 years using source control I have only had to do a rollback on one occasion. It should be an edge case with edge case support so developers learn to do things correctly in the first place.

With TFS 2010 if you really want to kick that nut in the head then enable Gated Check-in’s on all of your branches. Then developers can’t check-in until the build with all of the tests pass.

Conclusion

I really liked this post. So much so that I bothered to write a response. It is always good when people that have had to move from SVN to TFS describe the differences once they have worked with it for a while. There are always things that are different and Microsoft even had to publish a VSS to TFS guide because of the differences there.

Introduction to Team Foundation for Visual SourceSafe Users