行业报告源控制工具

Question

我正在寻找独立的行业报告,比较和对比各种源控制工具.特别是,我关心Clearcase vs Sourcesafe vs SVN,但如果报告包含其他SCM系统那么好.

对于想要了解他们切换到SVN的确切内容的客户,我需要这个(是的,来自Clearcase和VSS).换句话说,我可以用它来将它卖给他们的业务.

我希望通过这些工具对开发人员的工作效率进行一些案例研究,并免费提供结果报告.

谢谢,肯特

Answer 1

当我第一次开始在没有源控制(yikes)的公司工作时,我找了类似的东西.当时的开发负责人基本上只考虑微软的东西,而小开发团队中唯一一个有SCC经验的人只使用过SourceSafe.

我对SVN有很多经验,所以我很有偏见,但我确实尝试过对SVN与VSS和TFS的评估.我真的很难找到关于VSS的任何积极的东西,除了那些将它与不使用源代码控制的人进行比较.

SourceSafe的

• Visual SourceSafe:微软的源代码销毁系统

  • 来自文章:
    • SourceSafe缺乏可用的分支支持[..] SourceSafe的合并支持与签入紧密集成,使得在将其检入树之前很难检查差异并测试建议的合并.由于支持水平较低,很容易将无效代码检入修订控制系统.
    • 更新本地工作区以匹配服务器时,应提醒您注意在服务器上删除的文件.(或者删除,因为可以从修订控制系统中检索旧版本.)如果不这样做,可能会导致项目中使用过时的文件,这通常会导致问题.[..] SourceSafe无法删除过期文件或提供任何警告.
    • SourceSafe的基本设计假设客户端值得信赖,始终正常运行,并且没有任何因素干扰导致数据损坏的通信.因此,SourceSafe是脆弱和不值得信任的.我曾在三个不同的工作岗位上与SourceSafe合作过.在每种情况下,最终SourceSafe数据库都已损坏.数据已损坏,工作已丢失,时间浪费在问题上.

• Visual SourceSafe版本控制:任何速度都不安全？

  • 来自文章:
    • 当使用创建然后开发源文件,检查给定里程碑中的文件,标记项目等的简单循环时,SourceSafe似乎合理地工作.但是,许多简单的操作会导致软件以各种微妙(有时甚至是不显眼)的方式失败.''可以轻松地从数据库中清除已删除的文件,从而阻止重建项目的先前版本.""
    • 用户可以合理地期望Destroy命令从用户的硬盘驱动器中删除文件的当前工作版本.用户也可能合理地期望Destroy命令从当前版本的项目中删除该文件.用户可能不希望从该项目的所有先前版本中删除该文件.

• CodingHorror:源代码控制:除了SourceSafe之外的任何东西

  • 来自文章:
    • SourceSafe在90年代后期是一个非常适合的源控制系统.不幸的是,SourceSafe从未在架构上更新以反映现代源控制实践.即使是最新版本的SourceSafe 2005,也绝对是1999年的大潮.
    • SourceSafe为您提供安全和控制的幻觉,同时让您的项目面临风险.
    • SourceSafe教会开发人员不良习惯:避免分支,独占锁定,轻松永久删除.

• http://www.wadhome.org/svn_vs_vss.html

• 来自http://svn.haxx.se/users/archive-2006-11/0242.shtml:

  • 默认情况下,VSS在处理文件时使用锁定.如果用户签出(锁定)文件,然后离开公司或休假2周,管理员必须手动解锁文件,如果其他人需要工作,当其他人回来时,你'你的手上弄得一团糟.从我记得的情况来看,合并并不是非常好.

短VSS与SVN(取自http://better-scm.berlios.de/comparison/comparison.html):

• VSS不是原子的 - 如果网络中断,电源耗尽(在服务器或客户端上)等,则存储库已损坏.SVN是原子的,要么整个变化进入,要么都没有
• VSS锁定文件 - 多个人无法同时在同一个文件上工作
• VSS中的更改是特定于文件的.SVN可以将多个文件中的更改作为一个"更改集"提交.
• VSS不跟踪每行更改.使用SVN,可以看到谁最后更改了一行,以及哪个版本("svn blame")

颠覆

非常简单的源代码管理系统.跟踪更改,使用更新 - 合并 - 提交模型,允许多个开发人员同时处理同一文件,并且subversion会自动合并他们的更改(如果可能).没有"魔法"发生.

通过TortoiseSVN集成到Windows/Explorer .通过VisualSVN集成到Visual Studio (50美元/开发人员) - 这实际上只是TortoiseSVN的前端.

与许多第三方工具集成,例如:

• 用于错误跟踪的 Trac
  • 在http://trac-hacks.org上有大量的插件/插件
• CruiseControl.NET用于持续集成(自动构建)

Svn缺点:

• 没有内置的合并跟踪(跟踪哪些变更集已合并,例如,开发到稳定分支)
  • 可以使用svnmerge/svnmergegui
  • 从SVN 1.5开始,内置合并跟踪
• 缺少"搁置"功能
  • 允许某人处理某些事情,并将其"搁置"到存储库中(不将其作为项目的一部分),其他开发人员可以将其提取出来.
  • TFS有这个
  • 可以使用修补程序或创建单独的分支来近似此功能.

Team Foundation Server(Visual Studio Team System)

使用SQL服务器作为后端(因此它是可靠的).有一套内置的工具,用于错误跟踪,项目规划,持续集成.

• 零售价格:
  • 工作组版本$ 469.98(5个用户限制)
  • 完整版$ 2,499.98

• 许可可能比这更复杂:许可白皮书

  • 对于直接访问TFS的系统的每个用户来说,似乎需要CAL(客户端访问许可证).例如,即使允许技术支持员工直接提交错误,也需要为该用户提供CAL.
  • Visual Studio Team Edition附带一个CAL - 但另外它们是〜$ 500的定价(根据我在论坛上看到的)
  • 这可能在TFS 2008中有所改变

• 从VSS迁移到TFS:http://manicprogrammer.com/cs/files/folders/st_jean/entry1118.aspx

• 性能问题:http://www.cornetdesign.com/2007/05/vststfs-performance.html

• http://weblogs.asp.net/rosherove/archive/2007/04/29/tfs-or-not-being-a-perfectionist-is-a-realistic-world.aspx
• http://jeremydmiller.blogspot.com/2005/07/impressions-from-vsts-talk-last-night.html
  • 来自文章:
    • VSTS显然是针对那些使用繁重的高级仪式流程的大型公司 - 我的雇主并非如此.我认为流程自动化是一件好事,但如果你的流程如此复杂以至于没有人能够了解整体,那么我认为你有一些严重的问题.
    • 我认为Menegay完全脱离摇滚乐的演示文稿的一部分是VSTS成为一个定向工作流工具,告诉每个人(特别是开发人员)他们应该做什么.作为项目记录保存的跟踪工具,我认为VSTS非常棒.使用像VSTS这样的主要沟通渠道是荒谬的.将开发人员变成无意识的僵尸,完全按照VSTS工作流程告诉他们做的事情听起来像是给我带来灾难的秘诀.更不用说开发人员保留率急剧下降.
• http://codebetter.com/blogs/eric.wise/archive/2007/05/31/bye-bye-team-foundation-server.aspx
  • 来自文章:
    • 我真的试图给团队基础服务器一个公平的动摇.我对它的看法如下:1.它通常比源安全更好的源控制系统.这真的很贵.管理屁股是一件痛苦的事.排除故障是痛苦的.
• 通过它的声音,合并/分支支持不如subversion,因为他们试图让它们对sourceafe用户"熟悉".这纯粹是轶事.

我超级简短的总结:

• VSS糟透了
• TFS似乎非常实用/有能力,但只要您的团队成长超过5人,就会非常昂贵
• SVN可用且经过充分验证,无需任何费用

它归结为我们 - TFS可能带来的好处并不值得付出巨大的额外成本.

值得一提的是,自从我写这篇文章以后几年之后.曾经负责的人不再在公司工作,我现在是开发经理,我们的团队规模是他们的3倍.我们使用SVN,VisualSVN + TortoiseSVN和Trac的组合.我认为dev中的任何人都不会想象不再使用这些工具.每个人都能够非常迅速地获得SVN,可能除了分支之间的合并之外,有些人仍然对自己做的事情没有信心.

Jeff Atwood(stackoverflow的创建者)在他的一个和Joel的播客上讨论了SVN:http://blog.stackoverflow.com/2008/06/podcast-10/