从 ClearCase 迁移到 Mercurial：您的主要技巧是什么？
我们很快将开始用 Mercurial 替换 ClearCase。我听说这是一件好事。变更模型与版本模型。未来的浪潮。我准备相信这一点。尽管如此，这还是让我感到害怕。嘿，Joel Spolsky 花了一段时间才理解其中的差异以及如何从 Mercurial 中获得最大的优势，所以我打赌我会遇到概念上的陷阱和陷阱。
有人有任何现实世界中的“如何理解 Mercurial”的技巧吗？任何可以帮助我弥合概念差距的具体建议。有关于不该做的事情的警告吗？我很高兴听到他们的声音。我已经阅读了与该主题相关的最接近的问题，以及 Mercurialtour 和许多其他博客。我主要对我可能遇到的任何陷阱或呃哦感兴趣。您可以传授的任何智慧都将受到赞赏。
We will soon start replacing ClearCase with Mercurial. I hear this is a good thing. The change model vs. the version model. Wave of the future. I'm prepared to believe this. Still, it kind of frightens me. Hey, it took Joel Spolsky a while to grok the difference and how to get maximum advantage out of Mercurial, so I'm betting I will run into conceptual traps and pitfalls.
Does anyone have any real-world "how to grok Mercurial" tips? Anything specific suggestions that will help me bridge the conceptual gap. Any warnings about things not to do? I'd appreciate hearing them. I've already read the closest questions on SO related to this topic, as well as the Mercurial tour and a number of other blogs. I'm mainly interested in any gotchas or uh-ohs I may encounter. Any wisdom you can impart will be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
peepcode meet Mercurial 视频值得一小时和 9 美元。
就陷阱而言，我认为人们在善变方面失败的最大原因是过于关注“他们过去如何做事”，而不是关注“他们为什么做这些事”。
人们会极力反对 Mercurial 的分布式特性来伪造文件锁定，但他们这样做是因为合并过去很困难，而现在则不然。
或者人们会尝试将修订 ID 自动更新到他们的文件中，因为过去可以在每个文件的不同修订点进行签出。现在不再是了，所以将它放在一个地方就可以了，那个地方通常是
hg id。或者这里有一个大问题 - Mercurial 会做出不可磨灭的更改 - 在您提交/推动更改之后，没有简单的方法（并且有很多困难/糟糕的方法）来随后更改该更改。你可以抵消它的效果，但你不能召回并摧毁它。当有人第一次推动变革时，他们希望自己没有经历这样的顺序：
然后他们会做两件事之一：
，或者
最后一件事，做出知情的决定决定多种可能的分支方式中的哪一种< /a> 您选择。我喜欢那篇文章中的选项一，其作者更喜欢不同的选项，但它提供了很好的比较对比。
The peepcode meet mercurial video is worth the hour and $9.
As far as gotcha's I'd say the biggest way I see people fail on mercurial is to get too hung up on "how they used to do things" instead of focusing on "why they did those things".
People will beat their heads against mercurial's distributed nature to fake up file-locking but they do that because merging used to be hard and now it isn't.
Or people will try to get revision ids automatically updated into their files because it used to be possible to have a checkout at different revision points for each file. It no longer is, so having it in just one place is fine and that place is usually
hg id.Or here's a biggie -- mercurial makes indelible changes -- after you've commited / pushed a change there's no easy way (and plenty of hard/bad ways) to subsequently alter that change. You can negate its effect but you can't recall and destroy it. The first time someone pushes a change they wish they hadn't they go through this sequence:
and then they do one of two things either:
or
One last thing, make an informed decision about which of the many possible ways to branch you select. I like option one in that article, and its author prefer's a different one, but it gives a great compare contrast.
您可能读过这篇文章，但我刚刚读过它，并认为这对我们来说是一个非常好的介绍（来自 SVN）：
http:// hginit.com
You probably read this, but I just read it and thought it was a very good intro for us (coming from SVN):
http://hginit.com
首先阅读：“什么是基本的每个开发人员都应该知道的clearcase 概念？”。
在这个答案中，我将 ClearCase 与 Git 进行了比较，但总体思路仍然正确：
ClearCase (Central VCS) 与 Git 或 Mercurial (DVCS) 有很大不同，这个答案详细说明了主要区别。
如果您可以在 ClearCase VOB 中放入任意数量的数据，则任何迁移路径都将涉及将数据重新组织到一致的存储库（即其中包含一致数据的存储库）
规划从 ClearCase 迁移时遇到的问题类似于：
First read: "What are the basic clearcase concepts every developer should know?".
In this answer, I compare ClearCase to Git, but the general idea remains true:
ClearCase (Central VCS) is very different from Git or Mercurial (DVCS) and this answer details the main differences.
If you can put as many data as you want in a ClearCase VOB, any migration path will involve reorganizing your data into coherent repo (i.e. repositories with coherent data in them)
The issues when planning for a migration from ClearCase are similar to: