几个月前，我的团队将我们的源代码控制从Visual SourceSafe切换到了Apache Subversion，我们并没有更开心。
最近我一直在研究Team Foundation Server，至少从表面上看，它似乎非常令人印象深刻。与 Visual Studio 有一些很好的集成，并且为 DBA、测试人员、项目经理等提供了许多很棒的工具。
这两种产品最明显的区别是价格。很难击败 Apache Subversion（免费）。Team Foundation Server 相当昂贵，因此额外的功能真的不得不让 Subversion 望而却步。
对我来说，这是两者之间最大的区别，我都使用过：
1) TFS 与进行开发的“Visual Studio 方式”紧密耦合。 这并不是说 TFS 与 VS IDE 紧密耦合，这意味着 TFS 努力保持熟悉的 Visual SourceSafe 的“签入”/“签出”范式，即使它真的不再是一个合适的模型。Subversion 的“提交”/“更新”概念在您的开发人员可能会花时间与网络断开连接时更加现实。TFS 期望开发人员始终连接到服务器。这是一个很大的减号。我个人发现 TFS 对文件在服务器和本地磁盘上的组织方式不够透明，因为与 Visual Studio 的紧密集成。即使是 TFS 的更大支持者也承认，它的连接签入/签出模型对于离线工作的开发人员来说并不是一个令人信服的选择。
2)成本。 那些说 TFS 不贵的人可能是很小的商店，或者不符合 TFS 的许可条款。您需要一个客户端访问许可证才能完成您所做的一切。您是只管理错误的经理吗？您需要约 250 美元的 CAL（零售 TFS 许可证中包含 5 个）。只想报告他们的问题的业务用户？250 美元的卡。开发商？250 美元（除非他们有 MSDN，在这种情况下它包括在内）。服务器？500 美元（如果您有 MSDN，则包括在内）。当然，向您出售 TFS 副本的人会告诉您，工作项跟踪对其他用户是免费的，但这些额外的用户只能看到他们自己创建的工作项，而不是整个团队的工作项，这不是在面向团队的敏捷环境中太有用了。当您拥有一个中型组织时，所有这些都加起来，当如此多的同类最佳产品（如 SVN 和 CruiseControl.net）的增量成本为 0 美元时，就很难证明其合理性。（不过，为了公平起见，我仍在等待非常好的 OSS 问题跟踪器）
3）项目结构。 在项目数量较少的大型团队中，TFS 可能会运行良好。如果您是内部的许多小型、未连接或松散连接的业务线应用程序，则 TFS 的结构可能会开始变得霸道。一方面，不可能定义项目本身的分类——您可以在项目中设置“区域”，但所有问题和文档都在“项目”的基本上下文中一起跟踪。创建新的“项目”通常很耗时，而且对于小努力来说是多余的。当然，SVN 没有这种功能，因为它只关注源代码控制，但如果您需要良好的小项目灵活性，SVN 和其他问题跟踪工具可能是更好的选择。
我的意见，对于它的价值：
对于拥有大型、预算良好的项目的大型团队，在开发人员几乎完全在 IDE 中工作的 Microsoft 商店中，TFS 是赢家。当您需要对项目集中执行策略时，TFS 也会胜出。
对于许多小型团队，有许多不同的小型项目，或者成本是一个问题的商店，或者开发人员的工作与源代码控制脱节的团队，请使用 SVN。
我很惊讶过去使用过 Subversion 的人甚至会想要/需要 TFS 源代码控制。
我对 TFS (2005) 的体验非常糟糕。我已经阅读了各种白皮书和指南，以了解如何正确构建源代码以满足各种开发需求。
我们的简单情况是，我们有一个用于主线开发的主干，以及我们从中集成更改和部署的集成分支，以及一个用于跟踪过去版本的发布分支，这是非常常见和直接的，但我们不断遇到问题。
我对 TFS 的主要问题：
......名单还在继续。我认为即使进行了所有集成，也有更好的免费替代方案。
我最近在 CodePlex 加入了一个开源项目。他们使用 TFS 进行源代码控制，我不得不说它绝对很棒。到目前为止，我对它印象深刻。我非常喜欢 IDE 集成以及分支和标记代码是多么容易。如果您已经正确配置了所有内容，那么向源代码管理添加解决方案就像单击两次。
现在。是否值得付出高昂的代价？我不这么认为。在 CodePlex 从事项目的好处是它让我获得了我需要的 TFS 经验，以防我以后必须在某个地方使用它。如果您想为您的源代码管理提供良好的 IDE 集成，请获取VisualSVN集成包。获得许多相同的功能（顺便说一句，在非域计算机上免费）是一项非常便宜的投资。
我们是一家 VS.NET 商店，我们实现了：
成本：0 美元 好处：无价
如果您是一个小团队，或者还没有准备好接受 WHO TFS 流程，那么 SVN 和开源工具是您的最佳选择。
正如其他人指出的那样，TFS 为您提供了比 SVN 以项目管理等形式提供的更多功能。两者都使用过，并与非常大的公司合作实施 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 功能大致相同。它们都进行分支和合并，都进行原子签入，它们都支持重命名和移动。我认为对于刚开始使用分支和合并概念的人来说，让分支在源代码管理资源管理器中可见是很好的。
TFS 真的没那么贵（也许是 1200 美元？）。与 SVN 相比，它也许是。与报告服务和 SharePoint 的集成很好，但同样，如果您不使用它，那也没关系。
我想说的是下载 TFS 的 180 天试用版并试一试。并排运行试验。我想无论你走哪条路，你都会很开心。
正如 Ubiguchi 指出的那样，TFS 不是版本控制产品。购买 TFS 并仅将其用于版本控制显然是浪费金钱。TFS 是一套集成的工具，用于自动化应用程序生命周期管理的所有方面（并且非常适合“企业”。
同样根据 Ben S 的帖子 - 我不明白你对锁的评论。TFS 中根本不需要锁。管理员可以将 TFS 配置为像 VSS（一些“不明智的”客户要求的功能）到“Get-Latest on Checkout”，我相信这也可以进行签出锁定。
但通过“正常”使用 TFS，“签出”会提示用户输入锁定类型 - 默认值应为“无”。用户可以选择签出（或签入锁）——但这不是必需的。如果您不想要锁，请不要使用它们。
TFS 确实会出于各种性能原因（使获取最新版本更快）和项目管理（我喜欢查看开发人员签出哪些文件以及他们的签出时间）来跟踪哪些用户在服务器上签出。
我对 SVN 不是很熟悉（我从未使用过它）——所以我不能评论“TFS 的合并更糟”——并且没有遇到 Ben S 报告的合并错误——但我已经很棒了使用 TFS 进行分支和合并的成功。
我知道 TFS 仍然很弱的一个用例是针对经常“离线”的用户。TFS 是一种“服务器产品”，它假定用户大部分时间都处于连接状态。离线体验在 2008 年版本中有所改善（2005 年很惨淡），但仍有很长的路要走。如果您的开发人员需要（或希望）经常长时间与网络断开连接 - 您可能会更好地使用 SVN。
使用 TFS 的 SVN 粉丝要考虑的另一个功能是SVN 桥，它允许用户使用 TortiseSVN 连接到 TFS。我的好朋友和我的同事广泛使用它并喜欢它。
关于缺少命令行的评论也让我感到惊讶 - 命令行工具非常广泛（尽管许多需要单独下载TFS Power Tools
我怀疑 Ben 的评论是基于对 2005 版本的评估，该版本显然是“Microsoft V1.0”产品。该产品目前处于 2.1 版本，不久的将来会推出版本 3。
TFS 是令人发指的。此时我使用 SVN（带 Live Mesh 进行备份）在本地进行版本控制，因为 TFS 存在许多问题。主要问题是 TFS 使用时间戳来记录您是否拥有最新版本，并将这些时间戳存储在服务器上。您可以删除本地副本，从 TFS 获取最新版本，它会说所有文件都是最新的。这是一个愚蠢的系统，无法保证您拥有正确版本的文件。这导致了许多烦恼：
虽然 TFS 支持合并，但它实际上是一个签入/签出系统。如果您编辑一个文件，您经常会发现它被其他开发人员锁定。有很多方法可以解决它，但是系统如此复杂，您总是会遇到问题。例如，我们的开发人员发现他们可以通过检查整个解决方案来绕过在 NTFS 中将所有文件设置为只读的问题，该解决方案对所有文件设置了排他锁。我这样做了几次，因为 subversion 具有相同的结帐语法，它不会获取锁。
最后，Team Explorer（客户端）高达 400 MB，TFS 服务器需要 SharePoint 和两天的安装时间。subversion 一键安装程序大约为 30 MB，它将在一分钟内为您安装服务器。TFS 有很多特性，但它的基础如此不稳固，你永远不会使用或关心它们。TFS 在许可证方面很昂贵，并且开发人员将浪费时间在 stackoverflow 上咆哮而不是编写代码：P
我的建议，Team System 不值钱。我都使用过，在使用 Team System 之后，我试图找到一个类似的替代品。基本上，您所支付的是集成，您可能会争论自定义支持，但我已经能够创建一个团队系统替代品，只需一点时间并将工具集成在一起。
我最近问了一个问题，关于其他人为提出团队系统替代方案做了什么。我还列出了我用来创建替代品的开发工具。希望通过这个答案和我提出的问题，您可以找到适合您的方法。
我不是团队系统的仇恨者，我只是认为这不值钱。这是一个非常好的工具，如果您不介意为此付出代价，那么请务必使用它。这就是我创建我想出的替代品的全部原因。我想要 Team System 提供的功能。
这是一个名为Ankhsvn的 VisualSVN 开源版本。现在 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% 免费的，可以帮助您完成源代码控制所需的一切。
TFS 不仅仅是关于源代码控制。如果您使用 TFS 提供的整个包、错误跟踪、构建、报告等，那么 TFS 是一个非常可靠的选择（肯定比 Rational 更好）。TFS 还与 Active Directory 很好地集成。
虽然如果你只是在谈论 SCM，那么我更喜欢 SubVersion。我不太喜欢 IDE 集成。我也喜欢 SVN 的 Trunk/Tags/Branches 结构约定，以及在分支之间切换的相对容易性。不过，在 TFS 中合并似乎更容易。Tortoise 的 UI 击败了 TFS，尤其是在将文件添加到 repo 方面。
我会说这真的取决于你的需求。TFS 非常好，我已经广泛使用它，但它非常针对企业级，如果您不需要所有这些功能，则可能没有必要。如果您确实需要这些功能（尤其是分支、可伸缩性、工作项跟踪等），那么每一分钱都值得。请记住，TFS 包括错误跟踪、工作项跟踪和源代码控制之外的其他功能。如果您有多个分支，或者如果您发现自己在 Subversion 中遇到一些缺乏功能或其他功能的问题，那么切换可能是个好主意。但除非有充分的理由切换，否则您应该避免切换源代码控制系统的成本和生产力损失。
在广泛使用这两者之后，我认为 Wedge 是在指出“TFS 包括错误跟踪、工作项跟踪和其他源代码控制之外的功能”。
但是，老实说，SVN 和 TFS 在可扩展性方面似乎相当平等，如果有的话，SVN 的源代码控制由于其固有的简单性而在 TFS 上具有优势。
如果您希望在源代码控制的同时进行工作项和错误跟踪，那么您要么选择 TFS，要么选择 SVN 和其他一些可能免费的工具，例如 bugzilla。虽然 TFS 确实将源代码控制和工作项跟踪集成在一起，但老实说，我认为 MS 应该免费提供它，作为多年来滥用 VSS 开发人员的道歉。
我用过 SVN 和 TFS。使用 TFS 的主要优点是它与 Visual Studio 的紧密集成。错误跟踪、任务跟踪都将集中在一个地方。为这些项目生成的报告将帮助利益相关者随时了解项目状态。
我正在做一个有 5 个人的项目，我们最近从 SVN 切换到了 TFS。整个过程就像一场噩梦。我们有从 XMLSpy 自动生成的代码，并且 TFS 不能识别在 VS2008 之外修改的文件。TFS 电动工具可以扫描您的结帐并解决此问题，但必须记住使用这些工具是一件很痛苦的事情。我们经常遇到的另一个问题是 TFS 中的默认合并工具。这是迄今为止我用过的最糟糕的合并工具。有人会认为 TFS 将能够处理基本的解决方案合并，但到目前为止情况并非如此。
内置的用户界面非常有用，但也有缺陷。如果我从我的解决方案资源管理器中签出，有时未签出已添加的文件。如果我从 Team Source Control 窗口执行此操作，它会完美运行。这是为什么？我期待 VS2010 中的 TFS，因为我听说过关于它的好消息，而 SVN 远非完美，但我希望其中一些功能能够更直观地发挥作用。
亚当
TFS 非常适合项目管理和跟踪，但是我觉得源代码控制不如 SVN。这是我对 TFS 的不满：
签入/签出模型
这对于 TFS 源代码控制来说是一个巨大的骗局。不幸的是，即使您不想，VS 也会自动为您签出项目。我曾经遇到过有人检查了一些文件然后去度假的情况。我负责重组目录结构，但由于一堆文件被签出给那个人，所以我没能做到。GUI 中无法撤消结帐，这意味着必须在命令行中一一完成。或者我必须弄清楚如何为此编写一个强大的 shell 脚本。
VS 需要做所有事情
有时我想编辑一个文本文件并签入。这需要我启动 VS 2010，这是一个巨大的野兽，只是为了编辑一个文件并签入。SVN 需要几秒钟的事情现在需要我一分钟.
正如其他一些人指出的那样，文件仅在未签出时才被标记为只读。如果你让它可写并在 VS 之外编辑它，TFS 将无法识别这一点。这使得编辑 VS 之外的东西很烦人。这意味着，启动 VS，签出文件，编辑另一个编辑器，签入 VS。
一些在 SVN 中很容易的操作现在变得很痛苦
也许我还没有弄清楚，但我发现回滚变更集对于 TFS 来说非常乏味。
将文件添加到不属于解决方案的源代码控制中是一件非常痛苦的事情。TFS 源代码管理资源管理器仅显示哪些文件在源代码管理中，而不是哪些文件不在（也许在某处有一个设置，我不知道）。使用 Tortoise SVN，我只需在文件夹上按 Commit 并选择要添加的文件。
我目前正在领导我公司针对我们目前使用的 Rational Suite 评估 TFS。到目前为止，TFS 2008 正在开发 clearcase + clearquest。开发环境集成是它真正闪耀的地方。
我的 10 美分：
TFS2005 是个笑话 - 难以安装，甚至更难维护 TFS2008 是稳定的 - 更易于安装、更简单的维护和有效的自动化构建。TFS2010 是史诗级的！- 安装是狗 eassssyyy。管理非常容易；这都是一个布局精美的 UI。将它与 VS2008 集成并不是那么容易，因为您无法在 vs2008 中创建项目，您必须使用 vs2010（这很愚蠢）。TFS2010 还允许您更改共享点项目位置，而不是拥有 TFS2008 的那些糟糕的子文件夹。TFS2010 也有像燃尽图这样的工具，对项目管理非常有用。就像 TFS2010 是为包括客户在内的整个制作团队服务的！虽然它仍然花费太多:(
还要记住，TFS 需要服务器硬件提供更多的功能。当然，至少有一个 Windows 服务器许可证。
正如我们公司所遵循的，最佳实践是使用 2 台服务器：前端（带有集成共享点）和后端专用的 sql 服务器（我们使用企业集群）。TFS 可以安装在 1 台机器上，但不应该。
相比之下，我们的 svn 服务器安装在具有 256mb 内存和 1 个 cpu 的虚拟 linux 服务器上，在执行 checkout-all 等常见任务时仍然快几个数量级。虚拟硬件是 vshpere 可以分配的最低硬件！磁盘虽然很快（SAN）。
我建议 TFS 需要至少 5000 美元的专用硬件，而 svn 服务器（在 linux 上）可以与当前基于 Windows 的操作系统过时的任何硬件一起运行。
在我看来，这取决于项目完成的情况和环境。如果您只有一个简单的小型项目，那么 SVN 非常棒。正如一些人已经写的那样，VisualSVN 很好地集成到 Visual Studio 中，您不必在本机文件系统上进行签入/签出。
TFS 非常适合版本控制，但如果您真正使用它的所有功能，效果会更好。在我看来，如果您使用工作项作为集成存储库来处理客户错误报告、新功能请求以及通过管理任务和相应的估计时间、使用时间和剩余时间指示。
真正有趣的是使用将工作项与源代码签入相关联的功能。有关详细信息，请参见此处。
我们是一个正在从 SVN 迁移到 TFS2010 的小团队。我们这样做的最大原因是集成了 Visual Studio 和用于错误跟踪的 WebAccess，这现在是 TFS 的一部分。
@Adam：希望我们会有更好的体验。还不能说...
我在过去 3 年中使用过 SVN（之前来自 VSS），最近不得不切换到 TFS2010。总体感觉是它比 SVN 更错误，除了与任务/错误的良好集成之外，我认为它对 SVN 没有优势。速度似乎也比 SVN 慢一些。
如果我现在要选择源控制，我仍然会选择 SVN。
关于工具： - AnkhSVN Visual Studio 插件与 TFS 源代码控制一样好 - Tortoise 比 TFS 对应好很多
TFS 很棒，如果您不需要非开发人员来获取 pm 东西。
我们的帮助台需要参与到这个过程中，而它只是没有削减它。
至少在 tfs 2005 中的构建管理也很糟糕，它甚至无法构建与 2008 slns 相比。我真的不喜欢我的源代码控制选择，这会影响我的部署选择，这就是为什么我的团队不是 svn 商店。
如果它只是基于源代码控制，我会选择 SVN。Visual Studio 的 AnkhSVN 免费插件在其新版本中得到了极大的改进。此外，您还获得了 SVN 的源代码，并且文档很棒！他们在 TFS 2010 源代码控制中更改了一些神秘的东西，如果没有源代码，排除故障可能会非常艰巨。另外，您依赖于 MSDN 团队来抽出文档，他们按照自己的时间表和自己的深度进行。
话虽如此，TFS 显然提供的不仅仅是源代码控制。它是一个ALM工具。将它与工作项、报告、自动化构建、门控签入、自动化测试等相结合，可以提供一些非常丰富的价值，这些价值只有通过将不同的工具与 SVN 连接才能获得。当然，拥有 SVN 的源代码并不是万无一失的。我已经进入了 SVN 的场景，仍然需要数周时间才能完全弄清楚发生了什么。
因此，我建议您从 ALM 的角度来看待它，看看您的公司是否会使用所有 TFS 功能，或者是否会使用同类最佳的策略（例如 JIRA）。
TFS 一英里。
我无意中使用基于 SVN 文件的方法给自己造成了太多问题。我经历过的源代码控制问题：TFS – 2 年内 0 个问题 SVN – 数不清...
是的，我知道 TFS 的价格对于大多数公司来说都是如此的耻辱。如果 MS 有一个合理的定价模式，他们可能会拥有更多的市场份额（和利润）。