代码之家  ›  专栏  ›  技术社区  ›  Binoj Antony

TFS vs SVN[关闭]

  •  60
  • Binoj Antony  · 技术社区  · 17 年前

    我更习惯于SVN(带乌龟客户端)、CVS和VSS。TFS是否具有SVN中的所有可用功能

    你们有没有人从SVN切换到TFS并觉得值得?
    另外,如果我们需要使用TFS,我们可能需要Visual Studio。

    [编辑]
    我对TFS和SVN的源代码管理特性更感兴趣,当然其他特性列表也很受欢迎。

    16 回复  |  直到 17 年前
        1
  •  84
  •   NileshChauhan    17 年前

    " TFS和SVN之间无法进行比较

    SVN :是源代码版本控制系统
    TFS :是一个成熟的软件开发管理系统,包括版本控制、发布管理、需求跟踪、文档发布等。

    两者都很好地使用IDE集成插件(例如,AcHSvn,Collabnet的插件)可用于VS2005,所以这不是要考虑的要点。

    选择考虑的标准 :
    -如果您有一个无预算或小预算项目,请选择 SVN
    -如果您只寻找版本控制系统,请选择 SVN ,如果您正在寻找完整的开发管理,请选择 TFS
    -如果您有耐心使用不同的集成工具(CruiseControl.Net、NUnit、NCover、FIT)来实现适当的开发环境,请选择 SVN TFS

        2
  •  32
  •   MrTelly    17 年前

    在18个月前使用TFS后,我发现它有缺陷、速度慢、烦人、搜索条件非常有限,而且它给人的感觉是一个由一群不感兴趣、报酬低、工作过度的技术人员匆忙推出的产品,他们被迫使用Sharepoint和其他MS技术,因为这正是市场营销想要的。说真的,那是一只狗,我宁愿用它!

    另一方面,SVN有点技术性,IDE集成是一件痛苦的事情,有时会让人感到困惑,但用户群庞大,大多数问题都可以通过快速提问来解决。

    你考虑过吗 Vault ? 效果很好,价格也不太贵。

        3
  •  24
  •   Chris Walter    12 年前

    如果您使用的是2013版本,并且使用的是基于Git的存储库,我只推荐TFS。我以前遇到过很多问题,认为它们是稳定的。

    • 不可能一次将多个文件发送到diff工具。当您想在合并之前检查更改,但不可用时,这非常有用。
    • 功能的可用性不一致。某些功能仅在IDE中可用,而其他功能仅在Windows资源管理器中可用,而其他功能仅在命令行中可用。
    • 向版本控制添加文件在IDE中不可用,仅在Windows资源管理器集成中可用。
    • 只能从IDE中访问工具架集,而不能通过Windows资源管理器集成访问工具架集。
    • 缺少一个统一的安装程序。仅仅安装TFS是不够的,还必须安装团队工具和电动工具才能获得基本功能。
    • 工具架集功能不合并。做私有分支的一种很酷的方法,本质上保证了你的代码会过时并停止工作。
    • 如果需要使用Visual Studio以外的编辑器,则必须在编辑文本文件之前手动解锁文本文件。
    • 签入和搁置UI基于已添加到TFS的可用文件,而不是文件系统中实际存在的文件。这使得丢失文件非常容易。(这实际上是VisualStudio处理项目文件的方式的问题,但这本身就是另一个问题)。
    • 由于前面提到的问题,使用非Microsoft工具编辑源代码是不必要的困难。
    • TFS配置已与源一起提交。这意味着,如果更改TFS服务器,则所有历史记录的配置现在都不正确。您可以使用一个默认配置来覆盖此行为,但它并不明显。
    • 除了基本级别外,不支持任何忽略过滤器。
    • 无法处理超过249个字符的路径。
    • 已解锁但未编辑的文件显示为已更改,即使它们尚未更改。区分已更改和未锁定将使Diff更容易,或者更好地完全取消整个已损坏的解锁系统。
    • Windows资源管理器图标覆盖图无法清楚显示文件是否已编辑。TFS中的所有文件都有一个绿色角,而修改后的文件会在图标底部添加一支铅笔。切换到红色角落进行修改将更容易看到或使用乌龟图标系统。
    • 较旧版本的Visual Studio在与较新版本的TFS集成时遇到问题。这意味着我们现在在源代码管理中有一个IDE版本依赖项。
    • 默认情况下,在不需要用户解决方案文件时包括这些文件。当然,我承认这可能是一个偏好的问题。
    • 糟糕的缓存可能会导致本地副本和服务器之间的差异无法准确反映。获取最新信息并发现自己实际上没有最新信息是非常令人沮丧的。
        4
  •  14
  •   Saulius Žemaitaitis    17 年前

    我在各种项目中使用SVN已经有1.5年了。到目前为止我使用的设置:

    这些设置没有任何问题,我明确建议使用SVN,因为它是免费的,而且很容易开始使用。还有许多项目管理/缺陷跟踪包与SVN集成(如 trac 例如)。

        5
  •  12
  •   achinda99    17 年前

    也就是说,如果您希望TFS发挥其所有的优势,并且愿意解决其难点,那么它是一个设置自动构建和发布的伟大工具。

        6
  •  10
  •   Sakkle    16 年前
        7
  •  9
  •   Reed Copsey    17 年前

    我两者都用过——但实际上,我已经将我的主要项目从TFS切换到SVN。我发现离线和匿名访问在我的项目中非常有价值。

    总的来说,我认为它们是可比的。我会选择你最了解的人,你是最幸福的人。我没有发现一个系统中的特定功能明显超过另一个系统中的功能。

        8
  •  7
  •   danswain    17 年前

    如果你熟悉svn,我会坚持下去。Tfs不是免费的,也不是简单的。它不仅仅是源代码控制。如果你是一个像我们这样的.net商店,并且你决定在整个开发周期中使用什么产品,那么它是一个竞争者,但是对于简单的源代码控制来说,这是一个过火的决定。

        9
  •  4
  •   Sam Wessel    17 年前

    对我来说,选择显然是TFS:

    • 虽然这两个系统的源代码管理相关功能可能相当等效,但它们可以通过TFS直接从IDE访问,而您必须依赖 TortoiseSVN 或使用SVN的其他外部工具。 几乎所有TFS任务都可以通过单击“解决方案资源管理器”选项卡进行访问。

    • 使用TFS进行合并要容易得多,即使对于复杂的合并(例如, SVN will add <<<<<<'s and >>>>>>>>>'s to your .csproj files ,因此您需要手动编辑它们,以便从VS再次打开它们。)

    虽然我认为这些原因足以让我更喜欢TFS而不是SVN,但我补充说:

    • TFS不仅仅是一个源代码控制工具(想想工作项、项目门户等等)

      过去,我在一个中型项目(12名程序员、3名测试人员、3名业务分析师)中使用过它,我们能够成功地将所有任务集中在TFS中(bug报告、项目文档、构建过程等)

      我并不是说使用SVN和其他第三方工具不可能做到这一点,但将所有东西很好地集成到一个产品中绝对是件好事。


    为了公平起见,TFS有两个明显的缺点:

    • 它的价格

    • 安装TFS相当痛苦,而SVN安装只需几分钟。

      在SQLServer2008上安装TFS2008非常复杂,您无法在PDC上安装TFS等。对我来说,这绝对是我使用Microsoft产品所经历的最糟糕的安装体验。

      也就是说,一旦安装,TFS就非常容易使用(特别是对于不熟悉源代码管理系统的程序员)


    在我当前的项目中,我从SVN开始,并很快切换到TFS。我很高兴我做到了。

    我决定切换的主要原因显然是SVN的整体错误行为(我使用的是 VisualSVN 作为服务器和 AnkhSVN 作为客户)。每周至少有一次,我发现自己花了数小时在神秘的AnkhSVN错误消息上。

    到目前为止,我还没有找到一个理由对改用TFS感到遗憾。

        10
  •  3
  •   craziac    17 年前

    我认为TFS不仅仅是源代码控制。如果你买得起,我一定建议你用它。例如,当您开始使用团队构建,或者使用工作项之类的东西时,您将看到TFS可以真正管理您的整个开发生命周期,提供一个丰富的环境,在这个环境中,报告、易用性、灵活的VS集成和可靠的源代码控制都集成在一起。

    服务器端确实需要一些熨斗。我不觉得它很慢,但是,它在VPN上运行良好,支持脱机工作。

    一个主要的缺点是安装过程(在服务器端)冗长、不灵活,在我看来(我来自一个应用程序打包和部署非常重要的领域),这是SQL server、Reporting Services、Sharepoint和webservices安装方式的一个坏例子。

        11
  •  2
  •   Ian Ringrose    17 年前

    TFS可以从SVN导入,但是SVN不能从TFS导入。因此,如果你没有找到一个好的理由,否则就使用SVN,因为以后更容易改变主意。

        12
  •  2
  •   Chris Halcrow    12 年前

    根据我的经验,SVN整体速度更快,更无痛。我将它与XCOPY部署脚本一起使用,与TFS相比,XCOPY部署脚本允许您以更快的速度进行工作和部署。

        13
  •  1
  •   Matthew Olenik    17 年前

    我没有TFS方面的经验,但IDE集成是您应该考虑的问题。TFS明显整合 很好地使用了VisualStudio。AnkhSVN是VS唯一可用的免费插件,即使在新版本中也经常出现问题。不过,我还没有尝试过VisualSVN。

        14
  •  1
  •   Michele Di Cosmo    16 年前

        15
  •  1
  •   Didaxis    14 年前

    赞成的意见:

    • 与VisualStudio的集成 . 如果您正在利用完整的Microsoft技术堆栈进行开发,这将是一个真正的优势。
    • 自动构建

    欺骗:

    • . 出于某种原因,选择Windows工作流基础作为定制TFS的许多方面的方法。简而言之,你需要一本关于Windows工作流的书来理解它,而我根本没有时间。非常令人失望。
    • 项目管理 . 我想工作项的概念很简单,但是有很多奇怪的地方让我感到困惑。在我看来,这太复杂了。来自Trac+SVN的背景,我更喜欢这里的Trac。再说一次,只是我的意见。
        16
  •  0
  •   Community Mohan Dere    9 年前

    如果不了解这些工具的功能及其局限性,将意味着您最终得到的工具无法满足您的需求。了解您的要求,并稍微阅读一下产品手册-大量信息可用于确定适用性。

    虽然我完全同意SVN的支持者,因为它是一个很好的工具(我在大学里使用过很多次),但我发现当您使用SP1版本和Studio 2010时,TFS通常在OOTB情况下更为合作。

    此外,还有一些不错的小插件,使TFS对我们这些习惯于使用并且通常也更喜欢SVN类型解决方案的人来说更容易接受,而且其中许多插件都有很好的支持:

    TeamReview for Code Review就是一个例子: http://teamreview.codeplex.com/ http://www.microsoft.com/pathways/teamprise/FAQ.htm

    这个问题对于TFS插件来说是一个很好的资源: What Add-Ons / Utilities are available for TFS?

    工作室2008->修补->工作室2010->修补->。净->SQL Server 2008RD/2012->修补->TFS->修补