Team Foundation Server vs. SVN and other source control systems [closed]

开发者_开发百科 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

We are currently looking for a version control system to use in our projects. Currently our team is less than 10 people. We have been using VSS for the last 5 years. I have never worked with SVN and other version control systems.

Up to now we have been using VSS, but nowadays more powerful source control systems exists like TFS, SVN, etc. We are planning to migrate our projects to Visual Studio 2010, so the first idea coming to mind is to start using TFS 2010.

My question is: how good is TFS compared to other source control systems? Is it a good idea using it, or should we rather use SVN (or any other system)?

---

Having worked with TFS, Git, Subversion, CVS and VSS, let me quickly summarize my experience:

• It's fair to say that both Visual SourceSafe (VSS) and Concurrent Versions System (CVS) are pretty much obsolete these days.
• Git is technically the most powerful tool, but requires some time to understand the concepts. It also plays most of its advantages only if you really go for a distributed scm approach. The number of third-party software supporting Git is increasing rapidly, but is not yet as ubiquitous as for SVN.
• Subversion (SVN) offers clean and easy-to-understand concepts with a fairly common-sense and generic approach. A vast amount of integration software for most IDEs and file managers, as well as a lot of extension software is available. Because of the use of standard protocols like HTTP and WebDAV, it also integrates with software that wasn't actually designed to work with SVN, such as Microsoft Office ("Windows Web Folders") and more. SVN would be my recommendation if you are planning for a more traditional, centralized SCM approach.
• TFS version control is tightly integrated with Microsofts "Visual Studio" product line and the rest of the TFS development lifecycle platform. For use outside Visual Studio, there are a number of tools and a command line interface, but it really doesn't make sense to use TFS without Visual Studio, believe me. TFS version control is technically one of the worst I've ever worked with. Reasons:
  • It needs explicit checkout of every single file you work with. The same file being checked out by more than one person at the same time means TFS sees a conflict, no matter whether these people actually changed anything.
  • TFS uses a "workspace" concept, where actions in your working copy are recorded on the server as you work. You can't just checkout multiple copies of the source tree to multiple folders, you need constant online connection to the server (there is an "offline" mode, but that messes things up). All changes to anything in the local working copy have to go through TFS client tools first, since files are downloaded as read-only.
  • The fact that TFS shows more conflicts in the UI than are actually there encourages users to just bulk-accept or bulk-reject changes, which leads to loss of changes in one way or the other. It thus obstructs your view to what is actually important, which is a dangerous thing for a version control system.
  • The UI integration in VS doesn't support many useful operations you need when working with a SCM system seriously, like atomic (server-only) creation of branches, Branching from earlier revisions, undeletion, reverting of changes of a given changeset, and many more.
  • It is horribly slow, because creation of a branch implies downloading a whole new copy of the source tree if done via the VS GUI. A simple rename of a folder is also really slow. All in all it seems to create a lot of network traffic for simple operations.
  • The built in "shelving" feature, where you can save away your current changes without checking them in, is a nice idea but very much useless in most scenarios, since it doesn't support conflict resolution or merging when you re-apply your shelved changes to your working copy. If creating branches was as simple, reliable, fast, and straightforward as e.g. in SVN, you wouldn't really need such a feature, since every developer could create their own branches to manage this requirement.
  • In our environment, a number of bugs have turned up in TFS version control where files that had actually been changed where not recorded as such, and in few cases files were reverted to an earlier version without notice. This really shouldn't happen in a version control system!

---

Team Foundation Server is a full Application Lifecycle Management suite. If you have a Professional, Premium, or Ultimate version of Visual Studio 2010 with an MSDN subscription, Team Foundation Server 2010 is now free. All of your Visual Studio users that fall under that classification, as well, and do not require an additional CAL. Other users, however, will require that you purchase CALs to stay compliant with the license.

Using Team Foundation Server 2010, you will get source control, process management, defect tracking, build services, reporting, project portals, and more. SVN is strictly source control. I have used both, and they are different beasts. It would be fair to say that the type of features offered by SVN are a subset of Team Foundation Server, on the whole. While there are third party connectors to make it easier to work with SVN inside of Visual Studio (free, I believe - as well), the native integration between Visual Studio and Team Foundation Server is fairly seamless. From an administrative standpoint, both on the server and project level, you have an excellent balance of ease of use and features.

For the last three years, or so - between two different employers - I have setup and installed Team Foundation Server and maintained it over its lifetime. Both companies have used it to their advantage to be able to bring ordered process to their SDLC. The MSF Agile v5 template, if you are an Agile/Scrum shop, is outstanding. Sprint planning and management has never been as easy with any tool as it is now.

Edit - Added information about small teams:

I noticed a comment to the question regarding small teams. Team Foundation Server 2010, given its price point, makes sense for small teams now, as well. I would not have recommended it with Team Foundation Server 2008, though. With the latest version, there is a very nice "Basic" configuration that provides a lightweight installation, sans reporting and portal functionality. You can also install it locally, as well, if you are a "one man shop" with this configuration (Microsoft actually lists it as an acceptable configuration for a client install.) I have it on my laptop for my POC work - having set up a nightly maintenance plan and moving my backup to Dropbox. Works very well for peace of mind. ;-)

---

Martin Fowler has an interesting post about this topic on his website.