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