Moving from ClearCase to Mercurial: your top tips?

Question

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.

Answer 1

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:

• Migrating from clearcase to mercurial (which you may have already read)
• Migrating away from ClearCase which reminds you that you will need to establish policies for branching and labelling quite different from those done with ClearCase (especially ClearCase UCM), since publication (push/pull) is another dimension unknown from a CVCS like ClearCase.

Answer 2

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:

1. damn!
2. I want to I undo that
3. I can't undo that?!
4. That's the stupidest thing I've ever heard!

and then they do one of two things either:

• take the time to figure out why mercurial make indelible a good thing

or

• go through huge contortions to remove a changeset from all their remote repos and swear that mercurial is broken

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.

Answer 3

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