几个月前，我的团队将源代码控制从Visual SourceSafe切换到了Apache Subversion，我们从此不再快乐。
最近，我一直在研究Team Foundation Server，至少从表面上看，它似乎非常令人印象深刻。与Visual Studio的集成非常紧密，并且为DBA，测试人员，项目经理等提供了许多出色的工具。
这两种产品之间最明显的区别是价格。很难击败Apache Subversion（免费）。Team Foundation Server非常昂贵，因此额外的功能实际上必须让Subversion脱颖而出。
Answers:
我最近在CodePlex加入了一个开源项目。他们使用TFS进行源代码控制，我不得不说这是绝对宏伟的。到目前为止，我对此印象深刻。我是IDE集成的忠实拥护者，它对代码进行分支和标记非常容易。如果已经正确配置了所有内容，则向源代码管理添加解决方案就像单击两次。
现在。值得高昂的价格吗？我不这么认为。在CodePlex上进行项目的好处是，它使我获得了所需的TFS经验，以备日后在某个地方使用它时使用。如果您希望对源代码管理进行良好的IDE集成，请获取VisualSVN集成包。要获得许多相同的功能（在非域计算机BTW上免费），这是一笔便宜得多的投资。
对于我来说，这是两者之间最大的区别，并且我都使用了两者：
1）TFS与进行开发的“ Visual Studio方式”紧密相关。 这并不是说TFS与VS IDE紧密结合，这意味着TFS努力保持Visual SourceSafe的熟悉的“签入” /“签出”范式，即使它确实不再是合适的模型也是如此。当您的开发人员可能会花时间与网络断开连接时，Subversion的“提交” /“更新”的概念要现实得多。TFS希望开发人员始终连接到服务器。那是一个很大的缺点。我个人认为，由于与Visual Studio的紧密集成，TFS在服务器和本地磁盘上文件的组织方式上不够透明。甚至TFS的更大支持者也承认，它的连接的签入/签出模型对于不工作的开发人员来说不是一个引人注目的选择。
2）费用。 那些说TFS并不昂贵的人可能是很小的商店，或者不符合TFS的许可条款。您需要做的所有事情都需要获得客户端访问许可证。您是只负责管理错误的经理吗？您需要约250美元的CAL（零售TFS许可证中包含5个）。只是想报告问题的业务用户？250美元的CAL。开发人员？250美元（除非他们拥有MSDN，否则包含在其中）。服务器？500美元（如果您有MSDN，则包括在内）。当然，向您出售TFS副本的人会告诉您，其他用户可以免费使用工作项目跟踪，但是这些其他用户只能看到他们自己创建的工作项目，而不能看到整个团队的工作项目，在面向团队的敏捷环境中太有用了。当您拥有一个中型组织时，所有这些加在一起，而当许多一流的产品（如SVN和CruiseControl.net）的增量成本为$ 0时，很难证明这一点。（为公平起见，尽管如此，我仍在等待非常好的OSS问题跟踪器）
3）项目结构。 在项目数量较少的大型团队中，TFS可能会运作良好。如果您内部有许多小型的，未连接的或松散连接的业务线应用程序，则TFS的结构可能开始变得霸道。一方面，无法定义项目本身的分类法-您可以在项目内设置“区域”，但是所有问题和文档都在“项目”的基本上下文中一起跟踪。创建新的“项目”通常很耗时，并且对于小小的努力来说是多余的。当然，SVN没有任何种类，因为它仅专注于源代码控制，但是如果您需要良好的小项目灵活性，则SVN和其他问题跟踪工具可能是更好的选择。
我认为，这是值得的：
对于拥有大型，预算充足项目的大型团队，在Microsoft商店中，开发人员几乎完全在IDE中工作，因此TFS是赢家。当您需要在项目中集中执行策略时，TFS也会胜出。
对于许多小型团队而言，其中有许多不同的小型项目，或者是成本问题所在的商店，或者团队的开发人员无法从源代码控制中脱身，因此可以选择SVN。
令我感到惊讶的是，过去曾经使用Subversion的人甚至对TFS源代码控制有需求。
我在TFS（2005）上的经历非常糟糕。我已经阅读了各种白皮书和指南，以了解如何为各种开发需求正确构建源代码。
在简单的情况下，我们有一个主干开发干线，还有一个集成分支，从中集成更改并从中进行部署，还有一个发布分支来跟踪过去的发布，这种情况非常普遍和直接，但是我们一直在遇到问题。
我与TFS的主要问题：
...清单继续。我认为，即使进行了所有的集成，也有许多免费的替代方案，它们的优势更为明显。
我们是VS.NET商店，我们实现了：
成本：0美元好处：无价
如果您的团队很小，或者不准备加入谁的TFS流程，那么SVN和开源工具是您的最佳选择。
正如其他人指出的那样，与SVN相比，TFS以项目管理等形式为您提供了更多功能。这是我的两分钱，在使用了两者并与非常大的公司一起实施TFS时。
1）如果您使用的是TFS 2005，请升级到TFS 2008。TFS 2008中有很多改进使其可以使用。
2）如果您住在Visual Studio中，并且想要集成IDE，请使用TFS。我已经使用了SVN集成，并且几乎总是退回到使用TortoiseSVN。
3）如果您喜欢将帐户与Windows身份验证集成的想法，请使用TFS。从这方面的可管理性很好。对于SVN可能会有一些迷惑-我不太肯定，但是如果您喜欢GUI驱动的管理，那么TFS很难被超越。
4）如果您需要跟踪指标或采用更简便的方法来实现诸如签入策略之类的方法，请使用TFS。
5）如果有人不是MSFT则不会实现它，请选择TFS。
6）如果您不仅要执行.NET（Java工作，Eclipse等），还可以使用SVN。是的，那里有很好的产品（例如Teamprise）可以与TFS很好地配合使用。但是除非其他语言仅占您商店的一小部分，否则请坚持使用SVN。
除此之外，两者的SCM功能都差不多。他们都进行分支和合并，都进行原子检入，都支持重命名和移动。我认为对于刚开始使用分支和合并概念的人来说，让分支在Source Control Explorer中可见是很好的。
TFS确实不那么昂贵（也许是1200美元？）。与SVN相比，也许是。与报表服务和SharePoint的集成很好，但是同样，如果您不使用它，那也没关系。
我要说的是下载TFS的180天试用版，然后试一试。并排进行试用。我认为无论走哪条路，您都会感到幸福。
正如Ubiguchi指出的那样，TFS不是版本控制产品。购买仅用于版本控制的TFS显然是浪费金钱。TFS是一套集成的工具套件，可自动执行应用程序生命周期管理的各个方面（并且几乎适用于“企业”）。
同样在Ben S的帖子中-我不理解您对锁的评论。TFS根本不需要锁。管理员可以将TFS配置为像VSS（某些“不明智的”客户所要求的功能）一样工作到“结帐时获取最新信息”，我相信它也可以结帐。
但是通过“正常”使用TFS，“签出”会提示用户输入锁类型-默认值应为“无”。用户可以选择签出（或签入锁定）-但这不是必需的。如果您不想使用锁，请不要使用它们。
TFS确实会出于各种性能原因（使最新版本更快）和项目管理（我喜欢查看哪些开发人员已检出文件以及检出时间长短）两者来跟踪哪些用户已在服务器上检出。
我对SVN并不是很熟悉（我从未使用过），因此我无法评论“与TFS合并会更糟”，并且还没有遇到Ben S报告的合并错误-但我做得很好使用TFS进行分支和合并的成功。
我知道TFS的一个用例仍然很弱，它是那些经常“脱机”的用户。TFS是一种“服务器产品”，它假定用户大部分时间都已连接。离线体验在2008年版本中有所改善（2005年令人沮丧），但是还有很长的路要走。如果您有需要（或希望）经常与网络断开长时间连接的开发人员，那么使用SVN可能会更好。
对于使用TFS的SVN粉丝，要考虑的另一个功能是SVN Bridge，它是一个代码复合体，允许用户使用TortiseSVN连接到TFS。我的好朋友和我的同事广泛使用它并喜欢它。
同样，关于缺少命令行的评论也让我感到惊讶-命令行工具种类繁多（尽管许多工具需要单独下载TFS Power Tools
我怀疑Ben的评论基于2005版本的评估，该版本显然是“ Microsoft V1.0”产品。该产品当前版本为2.1，不久将发布版本3。
TFS令人发指。此时，我在本地使用SVN（带有Live Mesh进行备份）进行版本控制，因为TFS有很多问题。主要问题是TFS使用时间戳记录是否具有最新版本，并将这些时间戳存储在服务器上。您可以删除本地副本，从TFS中获取最新版本，它会说所有文件都是最新的。这是一个愚蠢的系统，无法保证您拥有正确版本的文件。这导致许多烦恼：
尽管TFS支持合并，但它实际上是一个签入/签出系统。如果您编辑文件，通常会发现该文件已被其他开发人员锁定。有很多解决方法，但是系统非常复杂，您总是会遇到问题。例如，我们的开发人员发现，通过签出整个解决方案可以解决所有在NTFS中设置为只读的文件的问题，该解决方案对所有文件设置了排他锁。我这样做了几次，因为subversion的结帐语法相同，但不获取锁。
最终，团队资源管理器（客户端）的容量高达400 MB，TFS服务器需要SharePoint和两天的安装时间。Subversion一键式安装程序约为30 MB，它将在一分钟内为您安装服务器。TFS具有许多功能，但是其基础是如此不稳定，您将永远不会使用或关心它们。TFS的许可证价格昂贵，并且随着时间的推移，开发人员将浪费大量的时间在堆栈溢出上，而不是编写代码：P
我的建议是，Team System不值得。我已经使用过这两个功能，并且在使用Team System之后，我试图找到一个类似的替代产品。基本上，您需要支付的费用是集成费用，并且可以争论定制支持，但是我能够花一点时间创建一个Team System替换并将工具集成在一起。
我最近问了一个问题，关于其他人如何提出团队系统替代方案。我还列出了用于创建替代品的开发工具。希望有了这个答案和我提出的问题，您可以找到最适合自己的方法。
我不是一个讨厌Team System的人，我只是认为这不值钱。这是一个非常不错的工具，如果您不介意为此付出代价，那么请务必使用它。这是我创造出想出的替代产品的全部原因。我想要提供团队系统功能。
这是VisualSVN的开源版本，称为Ankhsvn。现在，collabnet接管了它，这要好得多。
如果您需要的只是源代码控制，那么TFS就是多余的。我以前的一位雇主在他们的企业中拥有TFS，VSS和Subversion。我们的企业中没有Active Directory或Exchange Server 2003，因此最终在TFS服务器上创建了单独的用户，以便开发人员可以使用它。我们在合并中遇到了本·席曼（Ben Schierman）提到的相同类型的问题，以及其他导致我们走向Subversion的错误行为。
TFS是否适合您，部分取决于您的预算，开发团队的规模以及可用于配置/维护解决方案的时间和人员。如果您想要TFS提供的其他问题跟踪，工作项和项目统计功能，那么值得您花些时间来研究其他替代方案。诸如JIRA（来自Atlassian Systems的产品）或Trac之类的产品可以与Subversion很好地集成，并以较低的价格提供项目或项目经理可能需要的监督。
在理想的环境中，具有Active Directory，Exchange Server 2003或更高版本，并有专门的存储库人员，TFS更有可能是一个不错的选择。
我在工作和在家中都使用过。他们俩都非常酷。我唯一建议使用TFS的时间是，如果您要使用的功能不只是源代码管理，那么它是更多的。如果您需要的只是源代码控制，那么SVN不会出错，这就是原因。
VisualSVN服务器这是一个完整的SVN服务器，带有一个不错的插件来管理它。它使您可以直接通过UI使用Windows身份验证。简单。
乌龟它的乌龟，足够说。
ankhsvn这是一个很棒的SCC插件。对于那些想要完全与VS IDE集成的用户，最新版本是完整的SCC插件。因此，您现在可以免费获得完全集成。
上面的设置是100％免费的，它将帮助您完成源代码控制所需的一切。
经过广泛使用，我认为Wedge注意到了“ TFS包括错误跟踪，工作项跟踪和源代码控制之外的其他功能”。
但是，老实说，在可伸缩性方面，SVN和TFS似乎相当平等，并且由于任何固有的简单性，SVN的源代码控制在TFS上也具有优势。
如果您希望在源代码管理中同时进行工作项和错误跟踪，则可以选择TFS，也可以使用SVN和其他一些可能免费的工具，例如bugzilla。虽然TFS确实将源代码控制和工作项目跟踪集成在一起，但老实说，MS多年来应该免费赠送它作为道歉，以免滥用这么多VSS的开发人员。
我正在与5个人一起进行一个项目，最近我们从SVN切换到TFS。整个过程一直是一场噩梦。我们具有从XMLSpy自动生成的代码，并且TFS无法识别在VS2008外部修改的文件。TFS Power Tools可以扫描您的结帐并解决此问题，但是必须记住要使用这些工具，这很痛苦。我们经常遇到的另一个问题是TFS中的默认合并工具。这是迄今为止我使用过的最糟糕的合并工具。有人会认为TFS能够处理基本的解决方案合并，但是到目前为止，情况并非如此。
内置的用户界面非常有用，但也存在缺陷。如果我从解决方案资源管理器中签出，有时未签出已添加的文件。如果从“团队源代码管理”窗口中执行此操作，则它会完美运行。这是为什么？我很期待在VS2010中使用TFS，因为我听说过很多很棒的东西，而SVN远非完美，但我希望其中的某些功能能更直观地发挥作用。
亚当
TFS非常适合项目管理和跟踪，但是我觉得源代码控制不如SVN。这是我的TFS牛肉：
入住/退房模式
这对于TFS源代码控制是一个巨大的缺点。不幸的是，VS会自动为您签出项目，即使您不想这样做。我一直处于有人签出一些文件然后去度假的情况。我负责重组目录结构，但无法完成，因为一堆文件已签出给该人。GUI中无法撤消签出，这意味着必须在命令行中一一完成。否则我必须弄清楚如何为此编写一个电源外壳脚本。
VS必须做的一切
有时我想编辑一个文本文件并签入。这需要我启动VS 2010，这是一个巨大的野兽，只需要编辑文件并签入。SVN花了几秒钟的时间现在花了我一分钟。
正如其他一些人指出的那样，仅当未检出文件时，文件才标记为只读。如果使其可写并在VS之外进行编辑，TFS将无法识别。这使VS之外的编辑变得烦人。这意味着，启动VS，签出文件，用另一个编辑器对其进行编辑，然后签入VS。
SVN中一些简单的操作现在很痛苦
也许我还没有弄清楚，但是我发现回滚变更集对于TFS来说非常繁琐。
将文件添加到源代码管理中（这不是解决方案的一部分）是一个巨大的难题。TFS源代码管理资源管理器仅显示源代码管理中的哪些文件，而不显示哪些文件（可能不存在此设置，我不知道）。使用Tortoise SVN，我可以简单地在文件夹上按Commit，然后选择要添加的文件。
我目前正在领导根据我当前使用的Rational Suite评估我的TFS。到目前为止，TFS 2008正在使用clearcase + clearquest。开发环境集成才是真正的亮点。
还要记住，TFS需要服务器硬件提供更多的功能。至少要有一个Windows Server许可证。
我们公司遵循的最佳实践是使用2台服务器：前端（具有集成的共享点）和后端的专用sql服务器（我们使用企业集群）。TFS可以安装在1台计算机上，但不能安装。
相比之下，我们的svn服务器安装在具有256mb内存和1 cpu的虚拟linux服务器上，在执行诸如checkout-all之类的常见任务时，速度仍然要快几个数量级。虚拟硬件是最低的vshpere可以分配！磁盘速度很快（SAN）。
我会建议TFS至少需要5000美元的专用硬件，而svn服务器（在Linux上）可以与当前基于Windows的os过时的任何硬件一起运行。
如果仅基于源代码控制，我会选择SVN。适用于Visual Studio的AnkhSVN免费加载项在其新版本中已得到极大改进。另外，您还获得了SVN的源代码，并且该文档非常棒！他们在TFS 2010源代码管理中更改了一些不可思议的功能，如果没有源代码，进行故障排除可能会非常艰巨。另外，您依赖MSDN团队来抽取文档，并且他们会按自己的计划和深度进行操作。
话虽这么说，TFS显然提供的不仅仅是源代码控制。这是一个ALM工具。将其与工作项，报告，自动构建，门控检入，自动测试等结合可以提供一些非常丰富的价值，而这些价值只有通过将各种工具与SVN连接才能获得。当然，拥有SVN的源代码并不是万无一失。我已经进入SVN场景，可能要花几周才能完全弄清楚发生了什么。
因此，我建议您从ALM的角度进行研究，看看您的公司是要使用所有TFS功能还是要采用最佳策略（例如JIRA）。