SVN vs. Team Foundation Server几个月前，我的团队将源代码控制从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希望开发人员始终连接到服务器。那是一个很大的缺点。我个人认为，由于与Visual Studio的紧密集成，TFS在服务器和本地磁盘上文件的组织方式上不够透明。甚至TFS的更大支持者也承认，它的连接的签入/签出模型对于不工作的开发人员来说不是一个令人信服的选择。在人们开始关注SVN上的git和Mercurial等DVCS选项的情况下，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和其他问题跟踪工具可能是更好的选择。 我认为这是值得的：
令我感到惊讶的是，过去曾经使用Subversion的人甚至对TFS源代码控制有需求。 我在TFS(2005)上的经历非常糟糕。我已经阅读了各种白皮书和指南，以了解如何正确地构建源以满足各种开发需求。 在简单的情况下，我们有一个主干开发干线，还有一个集成分支，从中集成更改并从中进行部署，还有一个发布分支来跟踪过去的发布，这种情况非常普遍和直接，但是我们一直在遇到问题。 我与TFS的主要问题：
...清单继续。我认为，即使进行了所有的集成，也有许多免费的替代方案，它们的优势更为明显。 我最近在CodePlex加入了一个开源项目。他们使用TFS进行源代码控制，我不得不说这是绝对宏伟的。到目前为止，我对此印象深刻。我是IDE集成的忠实拥护者，对代码进行分支和标记非常容易。如果已经正确配置了所有内容，则向源代码管理添加解决方案就像单击两次。 现在。值得高昂的价格吗？我不这么认为。在CodePlex上进行项目的好处是，它使我获得了所需的TFS经验，以备日后在某个地方使用它时使用。如果您想为源代码管理实现良好的IDE集成，请获取VisualSVN集成包。要获得许多相同的功能(在非域计算机BTW上免费)，这是一笔便宜得多的投资。 我们是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的结帐语法相同，但没有获得锁。 最终，Team Explorer(客户端)的容量高达400 MB，TFS服务器需要SharePoint和两天的安装时间。 Subversion一键式安装程序约为30 MB，它将在一分钟内为您安装服务器。 TFS具有许多功能，但是其基础是如此动摇，您将永远不会使用或关心它们。 TFS就许可证而言是昂贵的，并且随着时间的推移，开发人员将浪费大量的时间在堆栈溢出上，而不是编写代码：P 我的建议是，Team System不值得。我已经使用过这两个功能，并且在使用Team System之后，我试图找到一个类似的替代产品。基本上，您需要支付的费用是集成费用，并且可以争论定制支持，但是我能够花一??点时间创建一个Team System替代产品并将工具集成在一起。 我最近问了一个问题，其他人为提出团队系统替代方案做了什么。我还列出了用于创建替代品的开发工具。希望有了这个答案和我提出的问题，您可以找到适合自己的方法。 我不是一个讨厌Team System的人，我只是认为这不值钱。这是一个非常不错的工具，如果您不介意为此付出代价，那么请务必使用它。这是我创造出想出的替代产品的全部原因。我想要提供团队系统功能。
这是VisualSVN的开源版本，称为Ankhsvn。 如果您只需要源代码控制，则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，但尤其是在向回购添加文件方面。 我已经使用了SVN和TFS。 使用TFS的主要优点是它与Visual Studio紧密集成。 错误跟踪，任务跟踪将全部集中在一个地方。 为这些项目生成的报告将帮助利益相关者随时了解项目状态。 广泛使用这两者之后，我认为Wedge注意到了" TFS包括错误跟踪，工作项跟踪和源代码控制之外的其他功能"，这是值得的。 但是，老实说，就可伸缩性而言，SVN和TFS似乎相当平等，并且由于某种固有的简单性，SVN的源代码控制在TFS方面具有优势。 如果您希望在源代码管理中同时进行工作项和错误跟踪，则可以选择TFS，也可以使用SVN和其他一些可能免费的工具，例如bugzilla。尽管TFS确实将源代码控制和工作项跟踪集成在一起，但老实说，MS多年来应该免费赠送它作为道歉，以免滥用如此多的VSS开发人员。 TFS非常适合项目管理和跟踪，但是我觉得源代码控制不如SVN。这是我的TFS牛肉： 入住/退房模式 这对于TFS源代码控制是一个巨大的缺点。不幸的是，即使您不想这样做，VS也会自动为您签出项目。我一直处于有人签出一些文件然后去度假的情况。我负责重组目录结构，但无法完成，因为一堆文件已签出给该人。 GUI中无法撤消签出，这意味着必须在命令行中一一完成。否则，我必须弄清楚如何为此编写一个Power Shell脚本。 VS需要做的一切 有时我想编辑一个文本文件并签入。这需要我启动VS 2010，这是一个巨大的野兽，只是编辑文件并签入。SVN花了几秒钟的时间现在花了我一分钟。 正如其他一些人指出的那样，仅当未检出文件时，文件才标记为只读。如果使其可写并在VS之外进行编辑，TFS将无法识别。这使VS之外的编辑变得烦人。这意味着，启动VS，签出文件，用另一个编辑器对其进行编辑，然后签入VS。 SVN中一些简单的操作现在很痛苦
我说这真的取决于您的需求。 TFS非常好，我已经广泛使用了它，但是它非常针对企业级的，如果您不需要所有这些功能，则可能没有必要。如果您确实需要这些功能(特别是分支，可伸缩性，工作项跟踪等)，那么它们一分钱都值得。请记住，TFS包括错误跟踪，工作项跟踪和源代码控制之外的其他功能。如果您有多个分支，或者发现自己在Subversion中缺乏某些功能或其他功能而苦苦挣扎，那么切换是个好主意。但是，除非有充分的理由进行切换，否则您应该避免切换源代码控制系统在成本和生产率上造成的损失。 我正在与5个人合作一个项目，最近我们从SVN切换到TFS。整个过程一直是一场噩梦。我们具有从XMLSpy自动生成的代码，并且TFS无法识别在VS2008外部修改的文件。 TFS Power Tools可以扫描您的结帐并解决此问题，但是必须记住要使用这些工具，这很痛苦。我们经常遇到的另一个问题是TFS中的默认合并工具。这是迄今为止我使用过的最糟糕的合并工具。有人会认为TFS能够处理基本的解决方案合并，但是到目前为止，情况并非如此。 内置的用户界面非常有用，但也存在缺陷。如果我从解决方案资源管理器中签出，有时未签出已添加的文件。如果我从"团队源代码管理"窗口执行此操作，则它将完美运行。这是为什么？我很期待在VS2010中使用TFS，因为我听说过很多很棒的东西，而SVN远非完美，但我希望其中的某些功能能更直观地发挥作用。 亚当 我目前正在领导根据我当前使用的Rational Suite评估我的TFS。 到目前为止，TFS 2008正在使用clearcase + clearquest。 开发环境集成才是真正的亮点。 我的10美分：
TFS2005是个玩笑-难以安装甚至难以维护 还请记住，TFS需要服务器硬件提供更多的功能。至少要有一个Windows Server许可证。 我们公司遵循的最佳实践是使用2台服务器：前端(具有集成的Sharepoint)和后端的专用sql服务器(我们使用企业集群)。 TFS可以安装在1台计算机上，但不能安装。 相比之下，我们的svn服务器安装在具有256mb内存和1 cpu的虚拟linux服务器上，并且在执行诸如checkout-all之类的常见任务时仍要快几个数量级。虚拟硬件是最低的vshpere可以分配的！磁盘速度很快(SAN)。 我会建议TFS至少需要5000美元的专用硬件，而svn服务器(在Linux上)可以与当前基于Windows的os过时的任何硬件一起运行。 在过去的3年中，我一直使用SVN(之前是VSS)，最近不得不切换到TFS2010。总体感觉是，它比SVN更具缺陷，除了与任务/错误的良好集成外，我认为它与SVN相比没有优势。速度似乎也比SVN慢。 如果现在要选择一个源代码管理，我仍然会选择SVN。
关于工具： 我认为这取决于完成项目的情况和环境。如果您只有一个简单的小型项目，那么SVN很棒。正如一些人已经写道，VisualSVN可以很好地集成到Visual Studio s.t中。您不必通过本机文件系统进行签入/签出。
TFS非常适合版本控制，但如果您真正使用它的所有功能，则更好。在我眼中，如果您使用工作项作为集成存储库来处理客户错误报告，新功能请求并通过管理任务以及根据估计的时间，使用的时间和剩余时间指示。 我们是从SVN到TFS2010迁移过程中的一个小团队。我们这样做的最大理由是将Visual Studio和WebAccess集成在一起以进行错误跟踪，这已成为TFS的一部分。 @亚当：希望我们会有更好的经验。不能告诉... 如果仅基于源代码控制，我会选择SVN。适用于Visual Studio的AnkhSVN免费加载项在其新版本中已得到极大改进。此外，您还获得了SVN的源代码，并且该文档非常棒！他们在TFS 2010源代码管理中更改了一些不可思议的功能，如果没有源代码，进行故障排除会非常艰巨。另外，您依赖MSDN团队来抽取文档，并且他们会按自己的时间表和深度进行操作。 话虽这么说，TFS显然提供的不仅仅是源代码控制。这是一个ALM工具。将其与工作项，报告，自动构建，门控检入，自动测试等结合可以提供一些非常丰富的价值，而这些价值只有通过将各种工具与SVN连接才能获得。当然，拥有SVN的来源并不是万无一失。我已经进入SVN场景，可能要花几周才能完全弄清楚发生了什么。 因此，我建议您从ALM的角度进行研究，看看您的公司是要使用所有TFS功能还是要采用最佳策略(例如JIRA)。 TFS很棒，如果您不需要非开发人员，可以使用pm东西。 我们的服务台需要参与该过程，而这并没有减少它。 另外，至少在tfs 2005中的构建管理是有缺陷的，甚至无法与2008 slns进行构建。 我真的不喜欢我的源代码控制选择会影响我的部署选择，这就是为什么我的团队不是svn商店的原因。 TFS一英里。
我因使用基于文件的SVN文件方法而无意中给自己带来了太多问题。 是的，我知道TFS的价格对大多数公司来说都是因素，这真是太可惜了。如果拥有合理的定价模型，MS可能会拥有更多的市场份额(和利润)。 |
