Question

We have a group of ~10 devs. who write internal test SW only. Until now, all development has been ad hoc with only a couple developers using Mercurial in their own way. The rest of the people use no version control what so ever (I know). Configuration management has also been a bit ad hoc in the past.
Now parent company wants us to be more structured. Now we are in the process of forcing all code to be controlled in Mercurial until parent company hooks us up to their corporate ClearCase servers (a few months down the road).

We would like for someone in this forum to describe a proven process/workflow that covers development all the way through configuration management on both, Mercurial and then in ClearCase.

We are experienced in both tools (Mercurial and ClearCase), but not so much on setting up the processes around these tools. So if a proven process could be described here, then we would use that as a starting point to define our own processes for development and then for configuration management integration as well.

Using clearcase will be mandatory for us, so no need to explain the cons of clearcase.

Any help will be much appreciated.
Thanks.

Answer 1

There is no server bullet, and it really depends on how you intent to use ClearCase, which is a CVCS (Centralized VCS).
I have detailed the differences between CVCS and DVCS in:

• “What are the basic clearcase concepts every developer should know?” (it was between ClearCase and Git, but it does apply for Mercurial), and
• “Describe your workflow of using version control (VCS or DVCS)“

The only instance where I have seen such an integration works well (or at least “not too bad”) is between a DVCS and ClearCase UCM.

If your current Mercurial repositories are organized around the notion of “component” (see “ClearCase UCM – best practices using components“, which also explains what a component is, and that applies to any source control tool), then the following mapping is straightforward

one DVCS repo <=> one ClearCase UCM Component

That allows you to define:

• clear import procedures (based on clearfsimport)
• clear matching between Mercurial tags, and ClearCase UCM baselines (since the base ClearCase tags or “label” are applied on a file-by-file basis, said label aren’t good tool for modeling a DVCS revision. A DVCS tag reference the all repository, not some subset of files within said repo.)
• clear dependency management (Mercurial subrepos vs. ClearCase UCM composite baselines)