我们很快就会开始用Mercurial取代ClearCase。我听说这是a good thing。更改模型与版本模型。未来的浪潮。我准备相信这一点。不过，这有点吓到我了。嘿，Joel Spolsky花了一段时间来解决这个问题以及如何从Mercurial中获得最大的优势，所以我打赌我会陷入概念陷阱和陷阱。
有没有人有任何真实的“如何理解Mercurial”提示？任何具体的建议，将帮助我弥合概念上的差距。关于不做的事情的任何警告？我很感激听到他们。我已经阅读了与此主题相关的SO最接近的问题，以及Mercurial tour和其他一些博客。我主要对我可能遇到的任何陷阱或呃哦感兴趣。你可以传授任何智慧。
答案 0 :(得分：6)
peepcode meet mercurial video值得一小时和9美元。
就我所说，我认为最让人失意的方法就是过于依赖“他们以前做过的事情”，而不是专注于“为什么他们做那些事情”。
人们会反对mercurial的分布式性质来假装文件锁定，但他们这样做是因为合并过去很难，现在却不是。
或者人们会尝试将修订ID自动更新到他们的文件中，因为过去可以在每个文件的不同修订点进行结帐。它不再是，所以只在一个地方使用它很好，那个地方通常是hg id。
或者这是一个大问题 - mercurial做出了不可磨灭的改变 - 在你提交/推动改变后，没有简单的方法（以及大量的硬/坏方法）来随后改变这种改变。你可以否定它的效果，但你不能回想起并摧毁它。有人第一次推动改变，他们希望他们没有按照这个顺序进行改变：
然后他们做以下两件事之一：
或
最后一件事，就您选择的many possible ways to branch中的哪一个做出明智的决定。我喜欢那篇文章中的选项一，而且它的作者更喜欢不同的一个，但它给出了一个很好的比较对比。
答案 1 :(得分：4)
你可能已经读过这篇文章了，但我只是读了它并认为这对我们来说是非常好的介绍（来自SVN）：
答案 2 :(得分：2)
首先阅读：“What are the basic clearcase concepts every developer should know?” 在这个答案中，我将ClearCase与Git进行比较，但总的想法仍然是正确的：
ClearCase（Central VCS）与Git或Mercurial（DVCS）有很大不同，这个答案详细说明了主要区别。
如果您可以在ClearCase VOB中放置任意数量的数据，任何迁移路径都会涉及将您的数据重组为一致的仓库（即其中包含相关数据的存储库）
规划从ClearCase迁移时的问题类似于：