SVN vs. Team Foundation Server [closed]

Answer 1

As others have pointed out, TFS gives you a lot more features then SVN does in the form of project management and such. Having used both, and worked with very large companies in implementing TFS, here's my two cents.

1) If you are using TFS 2005, upgrade to TFS 2008. You'll thank me. There are a ton of improvements in TFS 2008 that make it workable.

2) If you live in Visual Studio and you want the IDE integration, go with TFS. I've used SVN integration and almost always drop back to using TortoiseSVN.

3) If you like the idea of accounts being integrated with Windows Authentication, go with TFS. The manageability from that end is nice. There may be hooks for SVN - I'm not positive, but if you like the GUI driven management, TFS is hard to beat.

4) If you need to track metrics or have easier ways of implementing things like check-in policies, go with TFS.

5) If you have people who won't implement it if it isn't MSFT, go with TFS.

6) If you do more than just .NET (Java work, Eclipse, etc) go with SVN. Yes there are very good products out there (like Teamprise) that work well with TFS. But unless the other languages are a small part of your shop, just stick with SVN.

Outside of that, the SCM features of both are about equivalent. They both do branching and merging, the both do atomic check-ins, they both support renames and moves. I think for people just getting started with the branching and merging concept, having the branches be visible in Source Control Explorer is nice.

TFS really isn't that expensive ($1200 maybe?). Compared to SVN it is, perhaps. The integration to reporting services and SharePoint is nice, but again, if you aren't using that, then it doesn't matter.

What I'd say is to download the 180-day trial of TFS and give it a go. Run a trial side-by-side. I think you'll be happy no matter which way you go.

Answer 2

Here is a open source version of VisualSVN called Ankhsvn. Its much better now that collabnet has taken it over.

Answer 3

My 10 cents:

TFS2005 was a joke - hard to install and even harder to maintain TFS2008 was stable - easier to installer, simpler maintenance, and automated builds that work. TFS2010 is EPIC! - installation is dog eassssyyy. Management is very easy; it's all a nicely laid out UI. Integrating it with VS2008 isn't so easy since you can't create projects in vs2008 you have to use vs2010 (which is stupid). TFS2010 also allows you to change the sharepoint project location instead of having those awful subfolders of TFS2008. TFS2010 also has tools like a burndown chart that is really useful for project management. It's like TFS2010 is for the whole production team including the clients! It still costs way too much though :(

Answer 4

TFS is great for project management and tracking, however I feel the source control is not as good as SVN. Here are my beefs with TFS:

Check-in/Check-out model

This is a huge con for TFS source control. Unfortunately, VS automatically checks out items for you, even if you don't want to. I've been in a situation where someone checked out some files and then went on vacation. I was in charge of restructuring the directory structure, but was unable to because a bunch of files were checked out to that person. There is no way in the GUI to undo the checkout, which meant it had to be done one by one in the command line. Or I had to figure out how to write a power shell script for this.

VS is required to do everything

Sometimes I want to edit a text file and check it in. This requires me to startup VS 2010, which is a huge beast, just to edit a file and check it in. Something that took a few seconds with SVN now takes me a minute.

As some others pointed out, files are marked read only if they are not checked out. If you make it writable and edit it outside of VS, TFS won't recognize this. This makes editing something outside of VS annoying. This means, firing up VS, checking out the file, editing it another editor, checking in in VS.

Some operations that were easy in SVN are now a pain

• Maybe I haven't figured it out yet, but I found that rolling back a changeset was very tedious with TFS.

• Adding files to source control, which are not part of a solution, is a huge pain. The TFS source control explorer only shows which files are in source control, not which ones are not (maybe there's a setting somewhere for this, I don't know). With Tortoise SVN, I could simply press Commit on a folder and select which files to add.

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

We're a VS.NET shop, and we implemented:

1. Bugzilla for issue tracking
2. Apache Subversion as a source code repository back-end
3. VisualSVN Server for managing SVN on the server
4. TortoiseSVN (in Windows Explorer) and AhnkSVN or VisualSVN (in Visual Studio) on the client
5. CruiseControl.NET for automated builds

Cost: $0 Benefits: Priceless

If you're a small team, or not ready to buy into the who TFS process, SVN and open source tools are the way to go.