任何硬件（ASIC）公司都使用mercurial（hg）

Question

您是否知道任何大型公司（最好是硬件）成功使用mercurial作为其版本控制系统（vcs。）

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

我最喜欢的理由：

1. 在h / w公司中进行过战斗测试。
2. 很好地处理大型二进制文件。
3. 很好地处理大型项目＆gt; 10G。
4. 非常合理地处理符号链接。
5. 提供原子签到。
6. 灵活的分支机制。
7. 合并工具似乎运作良好。
8. 用户永远不需要使用管理员命令。

我不喜欢CVS的原因：

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

我喜欢CVS的原因：

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

Answer 1

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

对于硬件公司和软件公司使用系统之间的唯一区别往往是RTL模块具有非常明确的接口，并且通常由一个人拥有，因此开发非常细分。这对于集中式系统实际上非常有效，因为减少了对分支的需求。开发人员并没有像往常一样对待脚趾。

我见过一家硬件公司尝试Mercurial，这是一团糟。并不是说它是错误的工具，而是他们有一个CVS思维模式，并试图让它像CVS一样工作。我写了一个相当啰嗦的帐户here。

我个人认为SVN非常适合硬件开发，特别是对于来自CVS的人。检查子树的能力也很有用。也就是说，我目前正在一个试图与SVN进行“功能分支”工作流程的地方工作，合并有很多陷阱。他们将来会考虑git / hg。然而，他们是一家规模小，进取的公司。

从CVS搬到Mercurial的公司进入了Perforce。对他们而言，这完全取决于支持合同，并有责任归咎于他人。对于用户......好吧....我认为它给用户带来了非常复杂的前沿。整个工作空间概念只是矫枉过正，分支管理很痛苦。作为一个系统，它有能力，但需要做很多工作。

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