有关源代码控制工具的行业报告

Question

我正在寻找独立行业报告来比较和对比各种源代码控制工具。我特别关心 Clearcase、Sourcesafe 和 SVN，但如果报告包含其他 SCM 系统，那也没关系。

我需要这个工具来帮助那些想要准确了解切换到 SVN（是的，从 Clearcase 和 VSS）可以获得什么好处的客户。换句话说，我可以用它来将其出售给他们的企业。

我希望已经使用这些工具对开发人员的生产力进行了一些案例研究，并免费提供结果报告。

谢谢， 肯特

Answer 1

当我第一次开始在一家没有源代码控制的公司工作时，我寻找类似的东西（哎呀）。当时的开发负责人基本上只会考虑微软的东西，而小开发团队中唯一有过SCC经验的人也只用过SourceSafe。

我拥有大量使用 SVN 的经验，所以不可否认我有相当的偏见，但我确实尝试对 SVN、VSS 和 TFS 进行评估。除了那些将 VSS 与根本不使用源代码管理进行比较的人之外，我确实很难找到任何关于 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，可以看到谁最后更改了一行，以及哪个版本（“svnblame”）

Subversion

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

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

与许多第三方工具集成，例如：

• Trac 用于错误跟踪
  • http://trac-hacks.org 上有大量的插件/附加组件
• CruiseControl.NET for 持续集成（自动构建）

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< /p>

• 性能问题：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 -现实世界.aspx

• < p>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

  • 摘自文章：
    • 我确实尝试过给予 Team Foundation 服务器公平的待遇。我对此的看法如下： 1. 一般来说，它是一个比源安全更好的源控制系统。 2. 真的很贵。 3. 管理起来很痛苦。 4. 排除故障很麻烦。

• 听起来，合并/分支支持并不像 subversion 那么好，因为他们试图让 sourcesafe 用户保持“熟悉”。这纯粹是轶事。

---

我的超级快速总结：

• VSS 很糟糕
• TFS 似乎非常有用/有能力，但是一旦您的团队超过 5 人，
• 就会相当昂贵 SVN 可用且经过充分验证，并且没有任何成本

这对我们来说 - 可能的好处TFS 不值得付出巨大的额外成本。

无论如何，我写这篇文章已经是几年后的事了。原来的负责人已经不在公司了，我现在是开发经理，我们的团队规模扩大了三倍。我们使用 SVN、VisualSVN + TortoiseSVN 和 Trac 的组合。我认为开发人员中的任何人都无法想象不再使用这些工具。每个人都能够很快地掌握 SVN，也许除了分支之间的合并之外，有些人仍然对自己做这件事没有信心。

---

Jeff Atwood（stackoverflow 的创建者）在他和 Joel 的一个播客中讨论了 SVN：https://blog。 stackoverflow.com/2008/06/podcast-10/

Answer 2

有很多地方可以相互比较，但它们几乎总是偏向于一种系统。

以下是我过去使用过的一些比较。
better-scm
动态比较网站
维基百科

维基百科网站实际上非常全面且易于阅读。

Answer 3

Forrester Research 每隔几年就会发布一份报告。 IBM 引用了 2007 版本，并且CollabNet，颠覆。

Answer 4

我们在工作中使用 SVN 已经大约一年了（来自 on-high）。我只能说，如果你想做合并，远离长杆SVN。严重地。这是有害的。对于基本的源代码控制来说就很好了。随着合并，它变成了一场噩梦。并且不要告诉我我们用错了它。我们已经尝试了一切。它只是没有被开发来正确地进行合并。但如果你决定这样做，我祝你比我们好运。