Should we migrate from svn to Team Foundation Server 2010?

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

From my experience, TFS as a source control server is not the right choice. Merges are terribly slow, check-in procedure is counter-intuitive and usually ends with locked files that only an administrator can unlock. SVN is far more mature, flexible and fast.

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].

Answer 3

It's more a psychological, than a technical question.

As to my opinion, you should not migrate and keep yourself simple. Having only 6 developers, you will not get to anything complicated enough to use even a portion of high-level TFS2010 abilities.

VisualSVN is a good tool that keeps you "integrated" enough. And it will be improved even better.

Answer 4

I'm a Java developer, but all my friends are .Net, they all seem to prefer SVN with Tortoise. SVN is well supported by the open source community as well.

Answer 5

Though this might help you make a decision; I would agree with Mitch. You've got to have a good reason to change. SVN is way mature and dependable then TFS. Plus, the TFS is primarily targeted towards Microsoft applications, compared to the scope of SVN which is way beyond TFS.

Answer 6

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 7

I used TFS when I had to, and hated every minute of it. It just stood in my way too much, and it took forever to do anything remotely. But mainly it's just my irrational hate. If one out of your six programmers is like me you'll have a problem. And programmers are more important than tools.

Answer 8

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 9

I had TFS at my last client, now my new client has subversion and its awful. No shelving is a real killer.

Did I mention its free with VS 2010

Answer 10

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 11

There seem to be many people recommending the switch to TFS, I'd like to go the other way.

I moved from working with SVN at a previous job over to TFS at a more recent job. I'd summarize it like this:

The integration is attractive, and there's nothing else which has as many parts all integrated together. The tradeoff is that each of those individual parts kind of sucks.

More Detail:

The source control system, while technically very good on the server, etc, is PAINFUL to use. Files are always marked read only and you have to explicitly check them out to edit them. This makes your life awful unless you're using the visual studio integration 100% of the time... And if you are using the visual studio integration, remember that it stores the SCC status of all your files IN THE CSPROJ FILE, so be prepared to deal with occasional confusion and failure because you added the file to TFS, but visual studio hasn't realized this (or vice versa).

The bug tracking system has poor and limited search, and the UI is hard to use. It reminds me a lot of old access database forms. Compare this to a nice clean web-based tracker and it's night and day.

Overall, most of the UI's have really poor usability. While you can get many things done using TFS, it won't be quick, and you'll have to click on far too many combo boxes!

Additionally, TFS has very tight integration with your domain. If 100% of your staff and all your build/test machines are all on the same domain then this is probably fine... but if you're not, then this will cause you some pain.

Answer 12

The only 2 things I can't stand about TFS: the peculiar Visual SourceSafe roots (File attribute locking? Really? In this decade?) and server-based centralization (decentralization, when done right, is so much faster and more efficient for most typical source control activities because you're doing this stuff locally then merging instead of having a large team hammering your server every time they want to branch or tag), and the lack of a pre-rolled highly scrum oriented and integrated system (I know there are some templates available, don't post links because I have them bookmarked already, Microsoft evangelists).

Answer 13

Personally, I wouldn't touch either Subversion or TFS with a barge pole given the choice.

Both of them have both been superseded by more modern source control paradigms and technology, in particular, distributed version control. Switching from SVN to TFS or vice versa is like switching from a reel-to-reel tape recorder to gramophone records when what you really want is an iPod.

Neither of them handle merging branches well. Subversion requires you to delete a branch after you've re-integrated it into trunk (either that or resort to complex workarounds to keep it alive); TFS only allows you to merge branches if one is an immediate parent of the other. Neither of them are reliable enough at this to give me enough confidence to endorse them.

If you want to switch from Subversion to anything else, you should be looking at distributed version control systems such as Mercurial or Git, both of which are vastly more capable and flexible, and both of which make merging branches a very easy and intuitive exercise.