svn - 是否有任何硬件 (ASIC) 公司使用 mercurial (hg)

Question

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

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

我最喜欢 perforce 的原因:

在硬件公司中经过实战考验。

可以很好地处理大型二进制文件。

处理大型项目非常好> 10G。

非常明智地处理符号链接(symbolic link)。

提供原子 checkin 。

灵活的分支机制。

merge 工具似乎运作良好。

用户永远不需要使用管理命令。

我不喜欢 CVS 的原因:

不支持原子 checkin 。

数据库可能会损坏。

可能需要管理员命令来修复用户错误。

我喜欢 CVS 的原因:

战斗测试。

大多数人至少对它有点熟悉。

Answer 1

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

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

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

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

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

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