Update, 2010-10-23 Note: After reading discussion on Martin Hinshelwood’s blog, I’ve decided to state clear I’m writing here about TFS 2008. Some of the points might not be relevant to TFS 2010.
I’ve been using both Subversion and Team Foundation Server (TFS). Because I first used Subversion and started using TFS afterwards, I had to get used to TFS flavors. I think TFS is great but to be honest there were a few things I missed from Subversion and a few things that really annoyed me when I started using TFS.
So, this is a list of strong and weak points of TFS from the perspective of a developer who switched to it after using Subversion.
- 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.
- 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….)
- It’s dedicated to Windows platforms only, but this is hardly a problem for a team who uses Visual Studio
- It’s not a free tool
- Complex installation
- Update, 2010-08-22 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)
- Update, 2010-10-23 Poor support for revert (roll back). It’s not that easy to rever a check in (especially if it includes lots of files). Official roll back instruction sounds like a workaround… Another resource: read more
- Integration with Visual Studio
- Integration with work items (bugs, tasks, scenarios, test cases, etc.) – in other words your team needs only one tool (Visual Studio Team System) for all project chores. This actually promotes TFS to be a more powerful tool that a source control only.
- Shelving changes – ability to set aside pending changes temporarily in order to switch to another task – read more
- SQL Server backend (e.g. backups)
To sum up, both Subversion and TFS are powerful. There’s not an easy answer which tool is better. Despite not giving a direct judgment, it really seems to me TFS is better for bigger projects – one tool needed for all kind of project tasks (work items, source control, bug tracking, planning). What are your thoughts?
P.S. Probably the list above would look differently if I first used TFS instead of Subversion