Search code examples
mercurialclearcase

Mercurial and Clearcase, moving existing repo to another view

We've been running out of a Mercurial repo from within a CC snapshot view successfully for some time now. We have the source repo on the view, and the team's base repo is a clone from that one. That keeps a layer of separation to make checkout-checkins in CC easier to manage.

Now, for reasons internal to where I work, we need to switch to a new view. How can we do this? There are other teams within the company checking in files directly to CC (hopefully we'll convince them away soon), so that should be a consideration.

How can I overlay our existing repo into a new view (and then I can rebase the team's base repo no problem)?

Solution

  • The problem is the delta that might exist between your current Mercurial repo and the new snapshot view (especially with a different config spec).

    Since the OP mentions in the comments that the config spec of the new view won't change, he suggest a simpler method than the one below:

    • Load the new snapshot view content
    • remove all its files from the disk (not from ClearCase)
    • copy the .hg directory of the original Mercurial repo in the new (empty) view
    • update the working tree of said Mercurial repo (all the files are back in their original place, but detected by ClearCase as hijacked)
    • cleartool update -overwrite in order to force ClearCase to erase those files by the versions from ClearCase. (see man cleartool update)

    Mercurial would then detect any change between the files restored by ClearCase and the ones managed in the repo.

    (Original answer)

    I would:

    • create a branch dedicated for that migration in Mercurial,
    • compare its content with the snapshot view (without putting yet any Mercurial repo in it)
    • import and resolve the differences from the ClearCase view to the Mercurial repo
    • and then, once the content is identical, clone the Mercurial repo directly within the snapshot view.

    The rest would be about:

    • fetching that dedicated migration branch to the team's base repo
    • merging that branch to the main development branch within team's base repo