SVN vs. Team Foundation Server [closed]

Question

A few months back my team switched our source control over to Apache Subversion from Visual SourceSafe, and we haven't been happier.

Recently I've been looking at Team Foundation Server, and at least on the surface, it seems very impressive. There is some great integration with Visual Studio, and lots of great tools for DBAs, testers, project managers, etc.

The most obvious difference between these two products is price. It's hard to beat Apache Subversion (free). Team Foundation Server is quite expensive, so the extra features would really have to kick Subversion in the pants.

• Does anyone have practical experience with both?
• How do they compare?
• Is Team Foundation Server actually worth the expense?

Answer 1

Also take in mind that TFS requires a LOT of more horsepowers from the server hardware. And at minimum one windows server licenses ofcourse.

Best practice, as our company followed, is to use 2 servers: front-end (with integrated sharepoint), and a dedicated sql server in the back-end (we use an enterprise cluster). TFS can be installed on 1 machine, but should not.

In comparation, our svn server is installed on a virtual linux server with 256mb ram and 1 cpu, and is still several magnitudes faster when doing common tasks like checkout-all. The virtual hardware was the lowest vshpere could assign! Disk is fast though (SAN).

I whould suggest that TFS requires dedicated hardware for atleast $5000, while svn server (on linux) can run with any hardware which is obsolete for current windows based os.

Answer 2

I'm surprised that someone who has used Subversion in the past would even have a want/need for TFS source control.

My experience with TFS (2005) has been pretty horrible. I've read all kinds of whitepapers & guidance as to how to properly structure your source for various development needs.

Our simple situation, where we have a trunk with mainline development, and integration branch where we integrate changes & deploy from, and a releases branch to keep track of past releases is very common and straightforward, but we are continually running into problems.

My main issues with TFS:

• Merging is a PAIN in comparison to subversion.
• There are unfixed bugs. I ran into one about renaming/merging that has been known for 2 years and a fix will never be released for 2005. We ended up moving our branch to a "broken" folder and we ignore it now.
• Putting read-only locks on your files is friction. Who says I need to edit batch files and build scripts inside of TFS so that it will "check it out" for me? Subversion knows which files changed. There are no readonly locks there.
• Speed. TFS is dog-slow over a WAN, and it's really only usable if I VPN into my work computer, which makes my dev experience really slow overall.
• Lack of good command-line and explorer integration. IDE integration is really nice for the day-to-day Get-Latest, adding files, and checking in, but when you need to do things across many projects, it's nice to have good tools at your disposal. And before someone jumps down my throat claiming tf.exe works well... it's not really a cmd line tool. For example, checking in code shouldn't pop up a modal dialog.

...the list goes on. I think even with all of the integration, there are free alternatives that are far superior.

Answer 3

If all you need is source control, TFS is overkill. One of my previous employers had TFS, VSS, and Subversion in their enterprise. We didn't have Active Directory or Exchange Server 2003 in our enterprise, so we ended up creating separate users on the TFS server so developers could use it. We had the same sorts of problems with merging that Ben Schierman mentioned, along with other buggy behavior that pushed us toward Subversion.

Whether TFS is the right call for you will depend in part on your budget, the size of your development team, and the amount of time and personnel available for configuration/maintenance of your solution. If you want the additional issue tracking, work item, and project statistics capabilities that TFS provides, it may be worth your while to look at other alternatives. Products like JIRA (from Atlassian Systems) or Trac integrate well with Subversion and provide the sort of oversight a project or program manager might at a lower price.

In an ideal environment, with Active Directory, Exchange Server 2003 or higher, and dedicated staff for the repository, TFS is more likely to be a good choice.

Answer 4

I am currently leading the effort to evaluate TFS at my company against the Rational Suite which is what we currently use. So far TFS 2008 is pwning clearcase + clearquest. The dev environment integration is where it really shines.

Answer 5

I am working on a project with 5 people and we recently switched from SVN to TFS. The entire process has been a nightmare. We have auto generated code from XMLSpy, and TFS does not recognize files modified outside of VS2008. The TFS Power Tools can scan your checkout and fix this problem but it is a pain to have to remember to use these tools. Another problem we constantly run into is the default merging tool in TFS. It is by far the worst merging tool I have ever used. One would think that TFS would be able to handle basic solution merges but so far that has not been the case.

The built in user interface is very useful, but it also has flaws. If I checkout from my solution explorer, sometimes files are that have been added are not checked out. If I do it from the Team Source Control window it works perfectly. Why is that? I look forward to TFS in VS2010 as I have heard great things about it, and SVN is far from perfect, but I would have expected some of these features to function a little more intuitively.

Adam

Answer 6

TFS by a mile.

I inadvertently cause too many problems for myself with SVNs file-based approach. Source control problems ive experienced: TFS – 0 problems over 2 years SVN – lost count...

Yes I know the price of TFS factors it out for most companies which is such a shame. MS might have a lot more marketshare (and profit) if they had a reasonable pricing model.