SVN与Team Foundation Server的比较

77
几个月前,我的团队将源代码控制从Visual SourceSafe切换到Apache Subversion,我们感到非常满意。
最近我一直在研究Team Foundation Server,至少从表面上看,它似乎非常令人印象深刻。它与Visual Studio有很好的集成,并且为DBAs、测试人员、项目经理等提供了许多出色的工具。
这两个产品之间最明显的区别是价格。 Apache Subversion(免费)难以超越。 Team Foundation Server相当昂贵,因此额外的功能必须真正超越Subversion。
  • 有没有人对两者都有实际经验?
  • 它们如何比较?
  • Team Foundation Server是否真的值得花这笔钱?
26个回答

88

以下是我使用过两者后发现的最大区别:

1)TFS 与“Visual Studio 方式”进行开发紧密相关。这并不意味着 TFS 与 VS IDE 紧密耦合,而是指 TFS 在保持 Visual SourceSafe 中熟悉的“检入”/“检出”范例方面存在困难,即使这种模型已经不再适用。对于那些可能会脱离网络一段时间的开发人员来说,Subversion 的“提交”/“更新”概念更为现实。TFS 希望开发人员始终连接到服务器。这是一个很大的缺点。个人认为,由于强烈的 Visual Studio 集成,TFS 对服务器上的文件组织方式和本地磁盘上的文件组织方式的透明度不如其他工具。即使 TFS 的支持者也承认,其连接的“检入”/“检出”模式对于断开连接的开发人员来说并不是一个令人信服的选项。在人们开始将目光投向像 git 和 Mercurial 这样的分布式版本控制系统(DVCS)以代替 SVN 的时候,在 TFS 的“检出”模式看来有点像恐龙。

2) 成本。 那些说TFS不贵的人可能是非常小的工作室,或者没有遵守TFS的许可条款。你需要为几乎所有操作获得客户端访问许可证。你是只管理漏洞的经理吗?你需要一个价值约250美元的CAL(零售TFS许可证包含5个)。想要报告问题的业务用户?250美元的CAL。开发人员?250美元(除非他们有MSDN,否则会包含在内)。服务器?500美元(如果您有MSDN,则包含在内)。当您拥有中型组织时,所有这些都会累积起来,并且当许多最佳产品的增量成本为0美元时,很难辩解,例如SVN和CruiseControl.net。 (公平地说,我仍在等待一个真正好的OSS问题跟踪器)

3) 项目结构。 对于大型团队中的少量项目,TFS可能运作良好。 如果您拥有许多小型、未连接或松散连接的业务线应用程序,则TFS的结构可能开始变得繁琐。首先,无法定义项目本身的分类法——您可以在一个项目内设置“区域”,但是所有问题和文档都在一个“项目”的基本上下文中跟踪。创建新的“项目”通常很耗时,对于小规模努力而言则过度设计。当然,SVN没有这种情况,因为它仅关注源代码控制,但如果您需要良好的小型项目灵活性,则SVN和另一个问题跟踪工具可能是更好的选择。

我的观点:

  • 对于有大型、精心预算的项目团队,在开发人员几乎完全在IDE中工作的微软公司,TFS是最佳选择。当需要集中执行项目策略时,TFS也是获胜者。

  • 对于许多小型团队,有许多各种各样的小型项目或成本成为问题的公司,或有离线源代码控制的开发人员的团队,请选择SVN。


2
这正是我在寻找的信息,谢谢。 - EnocNRoll - AnandaGopal Pardue
1
+1 for "still waiting for a really good OSS issue tracker" - me too...+1 for“仍在等待一个真正好用的开源问题跟踪器”- 我也是... - BlueRaja - Danny Pflughoeft
9
随着 Visual Studio 2010 的推出,微软公司已经将客户端和服务器许可证与 MSDN 包括在一起。因此,如果您的所有开发人员都有 MSDN 订阅,则他们可以免费使用,您的 TFS 服务器也是免费的。此外,商业用户无需购买许可证即可创建工作项或查看他们创建的工作项。如果有最多 5 名商业用户想要访问 TFS,则可以购买售价为 $500 的零售 TFS 服务器许可证,允许 5 名用户不需要 CAL。但是,额外的非 MSDN 用户会花费您每个 CAL 300 美元。 - MrHinsh - Martin Hinshelwood
我仍在等待一个真正好用的开源问题跟踪器。我们一直在使用Redmine,它有很多插件,非常可定制,权限和工作流也很好,可以与存储库关联,并且可以从提交中引用票据并添加时间/关闭票据。唯一的缺点是它对Ruby的Rails配置要求比较苛刻,除此之外我们非常喜欢它。 - StrangeWill
@StrangeWill:谢谢,我得试试! - Dave Markle
显示剩余2条评论

48

我很惊讶曾经使用过Subversion的人竟然还需要或者想要TFS源代码控制。

我的TFS(2005)体验非常糟糕。我阅读了各种白皮书和指南,以了解如何为各种开发需求正确地组织您的源代码。

我们的情况很简单,我们有一个主干进行主线开发,一个集成分支用于集成更改并从中部署,并且一个发布分支用于跟踪过去的发布,这非常普遍和直接,但我们不断遇到问题。

我对TFS的主要问题:

  • 与Subversion相比,合并非常麻烦。
  • 存在未修复的错误。我遇到了一个关于重命名/合并的错误,已知已经存在2年了,并且将永远不会为2005发布修复程序。我们最终将我们的分支移动到“损坏的”文件夹中,现在我们忽略它。
  • 将只读锁放在文件上非常麻烦。谁说我需要在TFS内编辑批处理文件和构建脚本,以便它会“为我检查它?Subversion知道哪些文件已更改。那里没有只读锁。
  • 速度。TFS在广域网上的速度很慢,只有在我使用VPN连接到我的工作计算机时才能真正使用,这使得我的开发体验总体变得非常缓慢。
  • 缺乏良好的命令行和资源管理器集成。IDE集成对于日常的获取最新版本、添加文件和检入非常好用,但是当您需要在许多项目之间进行操作时,拥有好的工具非常重要。在有人声称tf.exe工作良好之前,请不要跳下来...它并不是一个真正的cmd行工具。例如,检入代码不应弹出模态对话框。

......还有很长的一串问题。我认为即使考虑到所有的集成,也有免费的替代方案比它更优秀。


5
我们使用TFS进行分支和合并,但这给我们带来了噩梦。目前我们正在考虑使用SVN。 - Brian MacKay
1
SVN似乎更聪明,可以安全地自动合并,而这通常是我需要处理的合并类型。例如,两个用户将文件添加到同一项目文件中。如果两个人在不同区域的文件中添加方法,则自动合并也很有效。如果您修改了相同的位置,则合并工具必须启动。根据您使用的合并工具,这可能很难或中等(如果您拥有Beyond Compare,则很容易)。获取此行,该行,保存文件,解决冲突,完成。 - Ben Scheirman
我不同意关于SVN合并的观点。如果文件在分支和主干中都被编辑,当你尝试进行从分支到主干的合并时,会出现已知的问题。去年我们在办公室花了一个周末手动完成了一次非常复杂的合并。话虽如此,我不知道TFS是更好还是更差。我也想知道为什么专业源代码控制的黄金标准Perforce没有被提及。 - Steve Severance
如果你在分支方面遇到问题,那么更换工具是没有帮助的。所有的工具处理分支的方式都差不多。此外,微软在VS2010中大大改进了合并工具,但如果你有很多合并问题,那么你可能在关注点分离方面存在更大的问题。请查看ALM Rangers发布的TFS分支指南... - MrHinsh - Martin Hinshelwood
5
抱歉,不行。我认为自己在其他源代码控制系统方面很有能力,所以对SOC缺乏评论是不正确的。据我上次检查,几乎每次提交都会更改解决方案/项目文件。TFS应该能够盲目地处理这些文件中的合并。然而,即使在TFS 2005中,我几乎每天都遇到问题。这是工具的问题。尝试除了TFS之外的任何东西,你就会知道。虽然2010年可能会更好,但为什么要等待?从第一天开始,Git 对我来说一直非常稳定。 - Ben Scheirman
显示剩余3条评论

46

我最近在CodePlex上加入了一个开源项目。他们使用TFS进行源代码控制,我必须说它实在是太棒了。到目前为止,我对它印象非常深刻。我非常喜欢它的IDE集成以及分支和标记代码的简便性。如果你已经正确配置好了一切,将解决方案添加到源代码控制就像点击两下鼠标那样简单。

但值得花高昂的价格购买吗?我认为不值得。在CodePlex上参与项目的好处是让我获得使用TFS所需的经验,以防未来需要使用它。如果您想要好的IDE集成来管理源代码,可以获取VisualSVN 集成包。它是一个更加便宜的选择,能够提供许多相同的功能(对于非域计算机免费)。


2
内置于TFS中的构建功能并不是很好,即使您使用它,我建议您同时运行Cruise Control,这样您就可以真正独立于源代码控制。例如,TFS 2005无法构建VS 2008解决方案。 - DevelopingChris
11
我推荐使用AnkhSVN,它是一个很好的Subversion源代码控制插件,与使用TFS一样...除了工作项等功能,这些显然不是Subversion的一部分。 - galaktor
1
@Jeremy - 你在TFS中使用了哪些功能来标记你的代码库(引自:“...分支和标记代码有多容易。”)? - Russell
13
与SVN相比,TFS源代码控制工具很糟糕,在不使用“PowerTools”(回滚更改是一件“高级”事情吗?)的情况下,你几乎不能做任何事情,而这些工具也未集成在VS中。人们都说TFS很棒,从我所见,这对服务器似乎是正确的,但客户端工具很糟糕。 - Eduardo Scoz
1
@AlfredMyers 回滚功能于2012年添加到用户界面中。 - MrHinsh - Martin Hinshelwood
显示剩余5条评论

43

我们是一个VS.NET开发团队,并且使用以下工具:

  1. Bugzilla用于问题跟踪
  2. Apache Subversion作为源代码库后端
  3. VisualSVN Server用于管理SVN服务器
  4. TortoiseSVN(在Windows资源管理器中)和AhnkSVNVisualSVN(在Visual Studio中)作为客户端
  5. CruiseControl.NET用于自动化构建

成本:$0 好处:无价

如果你是一个小团队,或者还没有准备好使用TFS流程,那么SVN和开源工具是首选。


使用NUnit和Sharepoint,而不是Bugzilla。 - boj
1
除了Bugtracker.net排名第一,这里也是一样的。 - Johan Wikström
1
我们这里也使用TeamCity作为构建服务器,免费支持最多20个项目。 - ThiagoPXP
VisualSVN 3.0在非域计算机上是免费的(社区许可证),因此AnkhSVN不是唯一的“免费”选项 :) - bahrep

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功能大致相当。它们都可以进行分支和合并、原子签入,它们都支持重命名和移动。我认为对于刚开始理解分支和合并概念的人来说,在源代码控制资源管理器中可见的分支很不错。

TFS真的不那么昂贵(可能是1200美元)。与SVN相比,可能会更贵。与报告服务和SharePoint的集成很好,但是如果您不使用它,则无关紧要。

我想说的是下载TFS的180天试用版并尝试一下。并行运行一个试用版。无论您选择哪种方法,我想您都会感到满意。


很多内容都不太对 - 当然,我会在可以的情况下使用TortoiseSVN,但只是因为它非常棒,是我的首选工具,即使我已经安装了AnkhSVN。SVN可以轻松地与ADS集成 - 只需使用VisualSVN Server。许多优秀的缺陷跟踪器或项目管理工具都可以轻松地与SVN集成,并且超越了TFS的管理功能。在SVN中,检入策略非常容易,只需设置一个预提交挂钩,它甚至带有示例,并且还有许多其他您可以使用的挂钩,而TFS则没有。但是....第5点可能是最重要的。 - gbjbaanb

16

如Ubiguchi所指出的,TFS不是版本控制产品。只购买TFS作为版本控制工具显然是浪费钱。TFS是一套集成的工具,可自动化应用程序生命周期管理的所有方面(并且基本上面向企业)。

另外,根据Ben S的帖子,我不理解您对锁定的评论。在TFS中根本不需要锁定。管理员可以配置TFS以像VSS一样工作(某些“不明智”的客户所要求的功能)以在检出时进行“获取最新版本”,我认为这也会进行检出锁定。

但是通过TFS的“常规”使用,“检出”会提示用户选择锁定类型,而默认应该是“无”。用户可以选择检出(或检入锁定)-但不是必需的。如果您不想使用锁定,请勿使用它们。

TFS确实会跟踪服务器上哪些用户具有检出文件,原因是各种性能原因(使获取最新版本更快)和项目管理(我喜欢查看开发人员检出的文件以及其检出的时间长度)。

我不是很熟悉SVN(我从未使用过),因此无法评论“TFS合并较差”的说法,并且没有遇到Ben S报告的合并错误,但我在使用TFS进行分支和合并时取得了很好的效果。

我知道一个TFS仍然相当薄弱的用例是经常处于“离线”状态的用户。 TFS是一种“服务器产品”,假设用户大部分时间都连接。虽然离线体验在2008年版本中有所改善(在2005年版本中极为糟糕),但仍有很长的路要走。如果您有需要(或希望)经常长时间与网络断开连接的开发人员,那么您可能更适合使用SVN。

考虑到使用TFS的SVN粉丝,可以考虑使用SVN桥接器 一个开源项目, 它使得用户可以使用TortiseSVN连接到TFS。我的一位好朋友和同事广泛使用它并喜爱它。
此外,评论中提到缺乏命令行工具令我感到惊讶 - 命令行工具非常丰富(尽管其中许多需要单独下载TFS Power Tools)。
我猜测Ben的评论基于对2005版本的评估,而那显然是微软的V1.0产品。该产品目前已经升级到2.1版本,3.0版本即将发布。

现在每个MSDN副本都免费附带TFS客户端和服务器,所以它不再是浪费金钱了! - MrHinsh - Martin Hinshelwood
但是当我在2008年发布时,这是真实的(但马丁的更新很好!) - fuzzbone

10

TFS这个系统真是太差劲了。目前我使用SVN在本地进行版本控制(备份使用Live Mesh),因为我对TFS有很多问题。主要问题在于,TFS使用时间戳来记录你是否具有最新版本,并将这些时间戳存储在服务器上。你可以删除本地副本,从TFS获取最新版本,但它会说所有文件都是最新的,这是一个愚蠢的系统,不能保证你拥有正确的文件版本。这导致了很多烦恼:

  • TFS需要知道任何文件何时被编辑,因此你必须始终连接到服务器。
  • 如果你在IDE以外编辑文件,TFS就会混淆不清。此外,它还将NTFS中的所有文件设置为只读。

虽然TFS支持合并,但它实际上是一个签入/签出系统。如果你编辑了一个文件,你经常会发现它已被其他开发人员锁定。虽然有一些解决方法,但这个系统非常复杂,你总会遇到此类问题。例如,我们的开发人员发现,他们可以通过检出整个解决方案来解决NTFS中所有文件都被设置为只读的问题,这会在所有文件上设置排他锁。我偶尔也会这样做,因为Subversion有相同的签出语法,它不会获得锁定。

最后,Team Explorer(客户端)占用400 MB的空间,TFS服务器需要安装SharePoint并花费两天时间。Subversion一键安装程序大约30 MB,可以在不到一分钟的时间内为你安装服务器。虽然TFS有很多功能,但其基础如此不稳定,以至于你永远不会使用或关心它们。TFS的许可证成本高昂,并且开发人员将浪费大量时间在Stack Overflow上抱怨,而不是编写代码:P


8
我的建议是,Team System不值得花那个钱。我曾经使用过两者,但在使用了Team System之后,我试图找到一个类似的替代品。基本上你所付的钱是为了集成和定制支持,但是我已经能够用一点时间和工具集成来创建一个Team System的替代品。
最近我在提问其他人是如何找到替代方案的。我还列出了我用来创建替代品的开发工具。希望通过我的回答和问题,你能找到适合自己的方案。
我不是Team System的反对者,我只是认为它不值得那个价。它是一个非常好的工具,如果你不介意支付价格,那么请尽管使用它。这也是我创建替代品的原因,我想要Team System提供的功能。

8

这里有一个名为Ankhsvn的开源版本VisualSVN。 Collabnet接管后已经变得更好了。


3
同意!我以前试过它,与现在相比存在一些漏洞。现在它非常流畅。 - EnocNRoll - AnandaGopal Pardue

7
如果您只需要源代码控制,则TFS可能过于复杂。我以前的雇主在其企业中使用了TFS、VSS和Subversion。由于我们的企业没有Active Directory或Exchange Server 2003,因此我们最终在TFS服务器上创建了单独的用户以供开发人员使用。我们遇到了与Ben Schierman提到的合并问题相同的问题,以及其他错误行为,这促使我们转向Subversion。
选择是否使用TFS部分取决于您的预算、开发团队的规模以及可用于配置/维护解决方案的时间和人员数量。如果您想要TFS提供的附加问题跟踪、工作项和项目统计功能,那么看看其他替代方案可能是值得的。像Atlassian Systems的JIRA或Trac这样的产品可以很好地集成Subversion并以较低的价格提供项目或程序经理所需的监督。
在理想的环境中,配备有Active Directory、Exchange Server 2003或更高版本,并拥有专门的存储库人员,TFS更有可能是一个不错的选择。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接