我们很快就会开始用 Mercurial 替换 ClearCase。我听说这是a good thing。变更模型与版本模型。未来的浪潮。我准备相信这一点。尽管如此，它还是让我感到害怕。嘿，Joel Spolsky 花了一些时间来理解差异以及如何从 Mercurial 中获得最大优势，所以我打赌我会遇到概念陷阱和陷阱。
有没有人有任何现实世界的“如何理解 Mercurial”的提示？任何能帮助我弥合概念鸿沟的具体建议。任何关于不要做的事情的警告？我很高兴听到他们的声音。我已经阅读了与该主题相关的 SO 最接近的问题，以及Mercurial tour 和许多其他博客。我主要对我可能遇到的任何问题或呃哦感兴趣。任何你能传授的智慧都将不胜感激。
【问题讨论】：
标签： version-control mercurial clearcase
peepcode meet mercurial video 值得一小时和 9 美元。
就问题而言，我认为人们在善变方面失败的最大原因是过于关注“他们过去是如何做事的”，而不是专注于“他们为什么做这些事”。
人们会反对 mercurial 的分布式特性来伪造文件锁定，但他们这样做是因为合并过去很困难，而现在并非如此。
或者人们会尝试将修订 ID 自动更新到他们的文件中，因为过去可以在每个文件的不同修订点进行签出。它不再是，所以只在一个地方就可以了，那个地方通常是hg id。
或者这是一个大问题——mercurial 会做出不可磨灭的改变——在你提交/推动更改之后，没有简单的方法（以及许多艰难/糟糕的方法）来随后改变该更改。你可以否定它的效果，但你不能召回和破坏它。当有人第一次推动他们希望他们没有经历这个序列的改变时：
然后他们会做以下两件事之一：
或
最后一件事，就您选择哪个many possible ways to branch 做出明智的决定。我喜欢那篇文章中的选项一，它的作者更喜欢不同的选项，但它提供了很好的对比。
【讨论】：
您可能读过这篇文章，但我刚读过它并认为它对我们来说是一个非常好的介绍（来自 SVN）：
【讨论】：
首读：“What are the basic clearcase concepts every developer should know?”。
在这个答案中，我将 ClearCase 与 Git 进行了比较，但总体思路仍然正确：
ClearCase (Central VCS) 与 Git 或 Mercurial (DVCS) 非常不同，此答案详细说明了主要区别。
如果您可以在 ClearCase VOB 中放入任意数量的数据，那么任何迁移路径都将涉及将您的数据重新组织到一致的存储库（即其中包含一致数据的存储库）
计划从 ClearCase 迁移时的问题类似于：
【讨论】：