SVN vs. Team Foundation Server [closed]

Answer 1

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 2

TFS is great, if you don't need non-developers, to get to pm stuff.

Our helpdesk needs to be involved in the process, and it just wasn't cutting it.

Also the build management in tfs 2005 at least, is attrotious, and it can't even build vs 2008 slns. I really don't like that my source control choice, affects my deployment choices, this is why my team is not an svn shop.

Answer 3

TFS is heinous. At this point I version control locally using SVN (w/ Live Mesh for backups) because I have some many issues with TFS. The main problem is TFS uses time stamps to record if you have the latest version, and stores these time stamps on the server. You can delete your local copy, get latest from TFS, and it will say all files are up to date. It's a silly system that gives you no guarantee that you have the correct version of files. This results in numerous annoyances:

• TFS needs to be informed when any file is edited, so you need to be connected to the server at all times.
• TFS get confused if you edit files outside of the IDE. Further it sets all files to readonly in NTFS.

While TFS supports merging, it's really a checkin/checkout system. If you edit a file you will often find that it is locked to other developers. There are ways around it, but the system is so convoluted you will always run into the issue. For instance, our developers found that they can get around all files being set to readonly in NTFS by checking out an entire solution, which sets an exclusive lock on all files. I did this a few times because subversion has the same syntax for checkout, which does not acquire a lock.

Finally Team Explorer (the client) is a whopping 400 MB, TFS server requires SharePoint and two days to install. The subversion one click installer is roughly 30 MB and it will install the server for you in under a minute. TFS has many features, but its foundation is so shaky you will never use or care about them. TFS is expensive in terms of the license, and in the time developers will waste ranting on stackoverflow instead of writing code :P

Answer 4

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 5

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 6

I joined an Open Source project over at CodePlex, recently. They use TFS for their source control and I have to say that it's absolutely magnificent. I'm incredibly impressed with it, so far. I'm a huge fan of the IDE integration and how easy it is to branch and tag your code. Adding a solution to source control is something like two clicks, if you've already got everything configured properly.

Now. Is it worth the hefty price tag? I don't think so. The benefit to working on projects at CodePlex is it lets me get the experience with TFS that I need, in the event that I have to use it somewhere later. If you want good IDE integration for your Source Control, go grab VisualSVN integration package. It's a much, much cheaper investment to get a lot of the same features (free on non-domain computers BTW).