Should we migrate from svn to Team Foundation Serv

Question

We are with 6 developer and currently use Visual Studio 2008 Professional with SVN and Visual SVN. As soon as vs2010 is released we will upgrade from vs2008 pro to vs2010 premium.

However if Team Foundation Server has a proper source control included in vs2010 premium, then it does make sense to use it. We like SVN, but like tight integration of tools even better.

On the internet information on SVN versus TFS 2010 seems to be scarce. Hence my question here.

EDIT: This video looks very compelling. Is this marketing talk or real?

Thank you all for your replies! I absolutely appreciate this. A little more background info.

This is our current stack; vs2008 pro, Visual SVN, SVN, Jetbrain Teamcity. My main problem is that we use a lot of tools from different vendors which more or less integrate. Sometime more, mostly less. At least it takes a lot of time to set it up correctly.

We currently do not use branches, but we want to. Therefore we have to set up SVN from scratch (we looked into it carefully). So let me rephrase my question: Should we set up SVN or start using TFS?

Answer 1

I think TFS is fantastic. Having bug tracking and source control fully integrated with Visual Studio is a big time saver. The on-the-wire protocol isn't too chatty, so it's also suitable for work over the Internet if/when needed.

There are many other features that are also useful, such as the team portal, statistics tracking, tracking test histories, capturing test outputs as part of a bug (very handy!), etc.

They also have full command line support for scripting, automated builds, a standalone TFS client for use outside of Visual Studio (say by non-developers), and optional integration with third-party tools such as Eclipse for mixed Java/.NET shops.

The main downside is price -- but if you can afford it, I think it's the best system out there at the moment.

Answer 2

If you are a Microsoft shop, then TFS is a good fit.

If Subversion does everything you need, would you fix something that is not broken?

You have to have a reason to change.

[I use TFS at work and it works great, with very few problems. I use Subversion at home, simply because I need less infrastructure].

Update [2012/05/01]: If you are not a Microsoft shop, then Git and mercurial would now be the tools of choice.

Answer 3

Really, you should try it out with a new, test, system to evaluate it. Plenty of people hate TFS and some think its not suitable for their ways of working. Also its not so free when you have to start buying the better versions of VS for the added features that you'll want once you're addicted.

There are reviews on the web that are not by MS marketeers that show that TFS isn't the best thing since git. Martin Fowler's survey for one is very interesting (of the 54 responses, not one thought it was great or even good). Maybe his readers are less keen on the 'full lifecycle' dev tools than most developers, but then, maybe they're just the same as the rest of us. Similar reviews are available - including Forrester Research's piece (which I have read: executive summary, SVN is "teh win" of the standalone SCMs)

So, just because TFS is now included in VS does not make it the best there is. You need to evaluate it properly before switching.

Answer 4

SVN does source control. Its default client is the command line, but GUI tools exist.

TFS does source control, bug/issue tracking, automated builds, reporting for managers and can cure male pattern baldness. Its default client is Visual Studio.

If all you want is source control then SVN works, and why change what isn't broken. If all you want is tighter integration into Visual Studio then look at Ankh or VisualSVN.

If you want automated builds, continuous integration, check in policies and rules, reporting, issue tracking and you want it all in one then TFS is for you - assuming you don't venture outside of Microsoft Development Tools (generally - there are plugins for other IDEs). You can get the same thing with other FOSS tools, and wrap them together with sticky tape around SVN and that works too, it's just not as seamless and needs a little more investment.

However you're comparing a source control system to a development lifecycle management tool. TFS does source control, but it does so much more.

Answer 5

I've used both TFS 2010 and SVN (with Tortoise), Mingle, MediaWiki, etc.

Although TFS gives you Source Safe style integration with Visual Studio, that's where the niceties end. SVN is much better at version control, Mingle is a blindingly better collaboration tool and MediaWiki is a much better wiki.

If you need to test TFS's main offering as source control, then create several TFS projects, add some changes and try reverting to a previous version. You'll need a command prompt tool and it'll be sheer look if you happen to rollback the correct project after following the shoddy online instructions.

Answer 6

If you're only using it for version control, stick with SVN. If you've got Linux/Java solutions, stick with SVN. If you're MS only and you fancy using work items for requirement/bug tracking etc. (which I do like) consider the move to TFS but remember you'll need to budget for CALs so that people can access this information. If you want overnight testing/CI builds remember to budget for extra VS licences for your build server because teambuild (msbuild) can't build a VDProjs, Intel projects etc.

also... TFS 'seems'/'appears' to struggle with some really basic things e.g. how to ignore files you don't want to put in the repository and it frequently marks files as having been changed that diff shows as being identical.