1

I'm attempting to add support for reading ClearCase repositories to reposurgeon. I've been able to puzzle out most of what I think I need, but the documentation is a massive pile of confusing details that leaves one basic question obscure. How do I list all revisions in a CC repository?

The minimum thing I need would be a time-ordered sequence of lines each containing a revision ID (path, branch, revision level) and its parent revision ID.

Revisions for directories should be included because I think I'll need that to deduce deletions. If there's some way to force a listing of file deletion events, directory revisions can be omitted.

It would be more convenient if I could get a four-column listing: revision-ID, parent ID, committer name, and timestamp. Given this, massaging the report into a git fast-import stream would be almost trivial.

I'm still a little unclear on how VOBs relate to single-project repositories in other systems, so an invocation for "specified VOB" and another for "all VOBs" would be appreciated.

The consequence of a useful answer to this question is that I will jailbreak ClearCase, solving the problem of how to migrate complete histories out of it to Git.

ESR
  • 574
  • 1
  • 5
  • 10

2 Answers2

0

First, check my old answer "What are the basic clearcase concepts every developer should know". See also "ClearCase advantages/disadvantages"

TLDR: Clearcase is file-based, not repository-wide revision-based.

A cleartool lsvtree would list revisions for a single file.

But only (full) UCM baselines would give something resembling to a revision, and that only for an UCM component within a Vob.

It would be more convenient if I could get a four-column listing: revision-ID, parent ID, committer name, and timestamp. Given this, massaging the report into a git fast-import stream would be almost trivial.

That would be a cleartool lsbl -fmt, using a fmt_ccase syntax

cleartool lsbl -fmt "%n %[owner]Fp %d"

Note: getting the "parent" baseline is more complex: see "How to obtain previous baseline from stream".

See more on how to migrate ClearCase to Git. Without UCM, that would be a mess.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • VonC: What is it about UCM that is important? – ESR Feb 23 '20 at 18:18
  • @ESR UCM is the only mode in ClearCase where a collection of file versions is grouped inside a common label (baseline) within a group of file (component, akin to a Git repo). Without UCM, all you have left is a collection of separate files, each one with their own individual history. – VonC Feb 23 '20 at 18:25
  • I can't find the F modifier for the owner property query in the ClearCase docs. What is that supposed to do? – ESR Feb 23 '20 at 19:38
  • Are you on Windows? There would not be a F on Windows – VonC Feb 23 '20 at 20:21
0

For base clearcase (on windows) listing the revisions can be done in two ways:

  • clearexport_ccase

    The tool clearexport_ccase writes a textfile with most of the relevant informations of one VOB (one repository). The format is not described by IBM, as far as I know.

    • You see all but not file delete or file rename.
    • You can see merge operations.

  • cleartool lshistory

    The subcommand lshistory of cleartool writes text file (format can be given as parameter) which seems to contain all meta information of the versions of the versioned elements.

    Unclear is whether it contains the merge informations of elements.

With both outputs you do not get the versioned elements itself but only the database path. To retrieve the file from the database you have to use cleartool get.

  • Because base clearcase is file oriented each file is versioned by itself.
  • Building changesets from the file, versions must be done by putting all versioned files together by looking at branch, tag, author, checkin msg, checkin time ...

  • Merging is done file wise and can be done by real merge or drawing a merge arrow, which means to show a merge in the revision tree of a file.

    Merging can be changed by drawing merge arrows in the version tree of a file.

  • Additionally you have a config spec which defines which versioned elements you see in your view of a repository; e.g. they define which branch you see in your view. (Perhaps they can be ignored when converting a VOB.)

  • Reading the information from the clearcase database is time consuming, so it should be possible to get the meta information first, convert them to check the conversion and merge them afterwards with the downloaded file versions.

It exists a ClearCase to SVN converter which is working for base clearcase which converts file revisions to change sets. So it seems to be possible.

swh
  • 1