2

你知道有哪些大公司（最好是硬件）成功地使用了 mercurial 作为他们的版本控制系统（vcs.）

我有 svn/cvs/perforce 和一点 git 的经验。内部政治正在推动我们走向 cvs，尽管我觉得这是一个糟糕的选择：

我最喜欢 perforce 的原因：

  1. 在硬件公司中经过实战考验。
  2. 可以很好地处理大型二进制文件。
  3. 处理大型项目非常好> 10G。
  4. 非常明智地处理符号链接。
  5. 提供原子签入。
  6. 灵活的分支机制。
  7. 合并工具似乎运作良好。
  8. 用户永远不需要使用管理命令。

我不喜欢 CVS 的原因：

  1. 不支持原子签入。
  2. 数据库可能会损坏。
  3. 可能需要管理员命令来修复用户错误。

我喜欢 CVS 的原因：

  1. 战斗测试。
  2. 大多数人至少对它有点熟悉。
4

1 回答 1

4

你是对的。CVS 是一个糟糕的选择。缺乏原子检查足以在我的书中取消它的资格。人们喜欢它，因为他们知道它，但他们不明白它有什么问题。

硬件公司和软件公司使用系统的唯一区别往往是 RTL 模块具有非常明确的接口并且通常由一个人拥有，因此开发非常分段。由于减少了对分支的需求，这实际上与集中式系统非常有效。开发人员不会过多地踩对方的脚趾。

我见过一家硬件公司尝试 Mercurial，结果一团糟。并不是说它是错误的工具，而是他们有 CVS 的心态并试图让它像 CVS 一样工作。我在这里写了一个相当咆哮的帐户。

我个人认为 SVN 非常适合硬件开发，尤其是对于来自 CVS 的人。检查子树的能力也很有用。也就是说，我目前在一个尝试使用 SVN 建立“功能分支”工作流程的地方工作，并且合并有很多陷阱。他们正在考虑未来的 git/hg 。不过，他们是一家小型、进步的公司。

从 CVS 转移到 Mercurial 的公司最终选择了 Perforce。对他们来说，这完全是关于支持合同和责备某人。对于用户......好吧......我认为它向用户展示了一个非常复杂的前端。整个工作空间的概念只是矫枉过正，分支管理很痛苦。作为一个系统，它是有能力的，但需要做很多工作。

如果我要在另一家硬件公司部署 Mercurial，我会大量使用子存储库。我这样做是为了从 subversion 中取回子树检出的有用部分，即 RTL 模块可以被检出并单独分支。它也给了我一个集成项目的概念，这将是我将所有子模块拉入的项目。这在某种程度上将 RTL 版本与 RTL 开发分离，并促进使用相同模块的不同芯片。此外，通过保持模块分离，历史记录也保持隔离，从而更容易跟踪模块的更改。最后，它避免了我在另一个答案中描述的“数百名开发人员访问一个中央仓库并进入合并竞赛”的问题。

于 2012-06-26T13:25:33.247 回答