1

I'm writing a script which converts a project in my workplace from ClearCase to Mercurial + Jira. I'm having problems with moved files. I'm using 'lsact -long' to get files changed in an activity. The problem is that when, for instance, a directory was renamed, the change is only apparent in its parent directory and it's listed with 'describe' like so:

Added directory element "new_name". Uncataloged directory element "old_name

Trouble is, it doesn't specify explicitly that a directory moved, so it might be that someone deleted an old directory and created a new one.

How do I know whether files were moved in a directory changeset?

Amir Rachum
  • 76,817
  • 74
  • 166
  • 248

1 Answers1

1

For any migration to Mercurial or Git, I never bothered with that information.

I simply select a coherent revision from ClearCase (an UCM baseline, or a full label), and add it to the repository (Hg or git).
I repeat the process revision after revision.

Hg or Git will detect the renames (files or directories) automatically.

In other words, any metadata recorded by a VCS won't be translated as is in Git or Mercurial.
Regarding renames, those DVCS will analyze their respective revisions and deduces the renames if you ask them to, after having imported everything, and while using your repo (like a git diff -M for instance, or an hg log --follow.

That being said, if you want to tell Hg that an element is moved (as in "How to rename a directory in Mercurial and continue to track all file changes"), you can check (if not already pruned) the event history of that parent directory, or the one of the "new_name":

cleartool lshist -long ...

Those events could have recorded the rename or move operation.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Regarding the migration - when we migrate, we want the commit granularity in Mercurial to ideally be a ClearCase activity - i.e., every "ChangeRequest" (not sure if this is "global" CC terminology or our own definitions) should be a commit in Mercurial. – Amir Rachum Jan 15 '13 at 21:13
  • @AmirRachum ClearCase activity is a good unit, but in the end too complex to track (especially when it comes to deliver/rebase activities, which mask contributing activities (http://stackoverflow.com/a/13565533/6309 and http://stackoverflow.com/a/14022262/6309). – VonC Jan 16 '13 at 06:22
  • @AmirRachum I simply select baselines, from the oldest to newest, making sure they are *full* baselines, and copy their content into an Hg workspace, committing each one. You only need to keep in mind "one repo per UCM component" (instead of trying to import everything into one Hg repo). – VonC Jan 16 '13 at 06:24
  • How do you select the baselines? I'm not very proficient with CC. How can I create a directory with the contents of a certain baseline? – Amir Rachum Jan 16 '13 at 10:52
  • @AmirRachum first, are you using ClearCase UCM, or just base ClearCase? (http://stackoverflow.com/a/10614843/6309) – VonC Jan 16 '13 at 11:31
  • UCM, although I am not sure what this means. – Amir Rachum Jan 16 '13 at 11:58
  • @AmirRachum http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.hlp.doc/cc_main/c_hood_ucm_concepts.htm The idea is to create a dynamic view, make sure each baseline is a full one (as in http://stackoverflow.com/a/10527967/6309) and modify the config spec of the (non-UCM) dynamic view to select that baseline. Import only the last few (not *all* of them) – VonC Jan 16 '13 at 12:12
  • In a migration plan, you generally leave the previous VCS in a read-only mode for archive, and keep only the 3-4 latest baselines imported in your new VCS referential: it is quicker to set up: have a short history to work from in the new repo. – VonC Jan 16 '13 at 12:35
  • How can I create a non UCM dynamic view? – Amir Rachum Jan 16 '13 at 15:41