SVN vs. Team Foundation Server [closed]

Answer 1

TFS isn't just about Source Control. If you use the whole package that TFS offers, bug tracking, builds, reports, etc then TFS is a pretty solid choice (certainly better than Rational). TFS also integrates well with Active Directory.

Though if you are just talking about SCM, then I prefer SubVersion. I don't really like IDE integration. I also like SVN's convention of Trunk/Tags/Branches structure, and relative ease of switching between branches. Merging seemed easier in TFS though. Tortoise's UI beats TFS's hands down though, especially in regards to adding a file to a repo.

Answer 2

As Ubiguchi points out TFS is not a version control product. Buying TFS with the intention of only using it for Version Control would clearly be a waste of money. TFS is an integrated suite of tools to automate all aspects of Application Lifecycle Management (and pretty much geared to "The Enterprise".

Also per Ben S's post - I don't understand your comment about locks. Locks aren't required in TFS at all. Administrators can configure TFS to work like VSS (features demanded by some "unwise" customers) to "Get-Latest on Checkout" which I believe also does a check-out lock.

But through "normal" use of TFS a "check-out" prompts a user for the lock type - and the default should be "none". A user CAN select a check-out (or a check-in lock) - but it is not required. If you don't want locks, don't use them.

TFS does track which users have check-outs on the server for various both performance reasons (make get-latest faster) and project management (I like to see what developers have files checked out and how long their check-outs are).

I'm not real familiar with SVN (I've never used it) - so I can't comment that "mergeing is worse with TFS" - and haven't hit the merge bug Ben S reported - but I've had great success with branching and merging using TFS.

One use case I know TFS is still pretty weak at is for users who are regularly "offline". TFS is a "Server Product" that assumes the users are connected the majority of the time. The offline experience improved in the 2008 release (it was dismal in 2005) but still has a long way to go. If you have developers who need (or want) to often be disconnected from the network for long periods of time - you are likely better off with SVN.

Another feature to consider for SVN fans who are using TFS is the SVN Bridge a codeplex which allows users to use TortiseSVN to connect to TFS. I good friend and colleague of mine uses it extensively and loves it.

Also the comment about a lack of command line surprises me - the command line tools are extensive (although many require a seperate download of TFS Power Tools

I suspect Ben's comments are based on an eval of the 2005 release which was clearly a "Microsoft V1.0" product. The product is currently in 2.1 with Version 3 coming in the near future.

Answer 3

Also take in mind that TFS requires a LOT of more horsepowers from the server hardware. And at minimum one windows server licenses ofcourse.

Best practice, as our company followed, is to use 2 servers: front-end (with integrated sharepoint), and a dedicated sql server in the back-end (we use an enterprise cluster). TFS can be installed on 1 machine, but should not.

In comparation, our svn server is installed on a virtual linux server with 256mb ram and 1 cpu, and is still several magnitudes faster when doing common tasks like checkout-all. The virtual hardware was the lowest vshpere could assign! Disk is fast though (SAN).

I whould suggest that TFS requires dedicated hardware for atleast $5000, while svn server (on linux) can run with any hardware which is obsolete for current windows based os.

Answer 4

Having used both extensively, I think Wedge was on the money in noting "TFS includes bug tracking, work item tracking and other features beyond source control".

However, I can honestly say that SVN and TFS seem pretty equal in regards to scalability, and if anything SVN's source control has the edge on TFS due to its inherent simplicity.

If you want work-item and bug tracking alongside your source control then you either go for TFS or you go with SVN and some other, possibly free, tools such as bugzilla. While TFS does integrate both source control and work-item tracking together I honestly think MS should have given it away free as an apology for abusing so many developers with VSS over the years.

Answer 5

We are a small team in the process of migrating from SVN to TFS2010. Our biggest reason to do so is the integration in Visual Studio and the WebAccess for bugtracking, that is now part of the TFS.

@Adam: Hopefully we will have a better experience. Can not tell yet...

Answer 6

My recommendation, Team System isn't worth the money. I have used both and after using Team System, I tried to find a similar replacement. Basically what you are paying for is the integration and you could argue the customization support, but I have been able to create a Team System replacement with a little bit of time and integrating tools together.

I recently asked a question on what others have done to come up with a Team System alternative. I also list the development tools that I used to create the replacement. Hopefully with this answer and the question that I asked, you can find what works for you.

I am not a Team System hater, I just don't think it's worth the money. It is a very nice tool and if you don't mind paying the price for it, then by all means use it. It was the whole reason I created the replacement I came up with. I wanted the functionality Team System provided.