Should we migrate from svn to Team Foundation Server 2010?_问答_开发者

We are with 6 de开发者_Python百科veloper 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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

Where I work, have the group is migrating over to TFS from DOORS mainily for requirements, specifications, etc. They still use Perforce as the repository. I have used most of the repositories out there and each one has there own quirks.

To answer your question - what is the problem your trying to solve? Do you need a integrated solution to manage your documents, bugs, source control? TFS gives you the integration portion so that each time you check in code you can tag it back to a bug, a requirement, a specification. That is a great feature if your company uses a lot of process. Sounds like to me that your a small shop and you really don't need that kind of process. I would stick with what works until you grow bigger and your needs change.