1

I've been using git my entire development life, and just recently got assigned to an antiquated sourcebase that is unfortunately still using IBM Clearcase for Windows for its version control. I've been struggling to get a grasp on the basics, mostly because there are many things that don't have a clear analog to git, and there isn't much support available for Clearcase since nearly every business no longer uses it.

My main problem is I can't figure out how to checkout a different branch. I've created a snapshot view of a VOB(so in git terms, a local repo cloned from a remote), and I believe I'm on the master branch. I'm looking at it in Rational ClearCase Explorer. I then open up the "Type Explorer", select the VOB I'm working with, and select "branch types". From here I can see every single branch that's been created.

Let's say I want to check out branch "my_branch". I don't see any appropriate selection from the context menu upon right-click in this Clearcase explorer. The only options are "Clone", "Delete", "Rename" and "Properties". From cleartool, I run the command

find ./ -branch 'brtype(my_branch)' -print

and it returns the following:

./\vob\path\to\changed\file\myFile.cpp@@\main\MYPROJECT\my_branch

That's the branch I want, and I believe what this command is telling me that my_branch has changed myFile.cpp compared to my current branch. I want to see how myFile.cpp differs on my_branch compared to master. Now if this were git, I'd want to checkout that branch. But, nearly everything I do using checkout doesn't work.

In Cleartool, I try:

checkout -branch \main\MYPROJECT\my_branch

and I get back:

cleartool: Error: Element pathname required.

I would've thought that \main\MYPROJECT\ was the pathname. So instead I try to see what happens if I check out just that one file with:

checkout -unreserved ./\vob\path\to\changed\file\myFile.cpp@@\main\MYPROJECT\my_branch

It returns:

Checkout comments for "./\vob\path\to\changed\file\myFile.cpp":

and hangs indefinately, and never checks out that file.

What exactly am I doing wrong? How the heck do I check out this branch that I can see into my local view? Any help is valuable and appreciated, since Clearcase is such an arcane relic of the past these days.

IMSoP
  • 89,526
  • 13
  • 117
  • 169
blarglesz
  • 13
  • 2
  • 1
    Clearcase does not map well to commit-oriented systems. Clearcase is internally file-oriented and has a lot of weirdness. There were some add-ons to Clearcase that layered commit-like semantics onto it, so you'll need to be specific about what CC version and options they're using. – torek Jun 14 '21 at 12:44
  • I've never used it on Windows, only on Solaris, where the path separators are always `/`, but your `ct co` looks appropriate: it should find the `/main/MYPROJECT/my_branch` version (i.e., the rev number) of the named element and extract it. There are a lot of setup steps I've (rather thankfully) forgotten to get to this point though, maybe some of those are missing here. – torek Jun 14 '21 at 12:46
  • @torek Don't worry, this is ClearCase: on Stack Overflow, it has my name on it, since 2008. – VonC Jun 14 '21 at 13:00
  • @VonC: aha, yes, your cspecs list reminded me of several things I'd forgotten. Sounds like he has the Snapshot stuff going at least. We were forced to use dynamic views, when I was using CC. – torek Jun 14 '21 at 13:04
  • @torek dynamic views have their advantages, that Microsoft is trying to replicate with its VFS for Git (https://github.com/microsoft/VFSForGit). But the cspec itself would apply to both snapshot or dynamic views (minus the loading rules specific to snapshot views of course) – VonC Jun 14 '21 at 13:06
  • Mmn, I always thought of dynamic views as the Work Impediment System. You'd build your current setup, then make a change, then go to build again and suddenly the entire build is broken. Why? Because your `ct co` got you a frozen version of `foo.h` but you just picked up the new version of `bar.c` and `baz.c`, which depend on the *newer* `foo.h`. So now you spend a day figuring *that* out, by which time seven other files have updated on you... – torek Jun 14 '21 at 13:08
  • @torek Yes, using tag to freeze a version selection is one way to guard against the "LATEST" auto-update issue. With UCM, you would be using Baselines (same idea, on a component level) – VonC Jun 14 '21 at 13:27
  • @torek The main idea for dynamic views was: being able to be able to work on a large set of files, something that, again, Microsoft is keen to replicate, considering the sheer size of their Git repository (https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/). And the all metadata of derived-object and configuration record " (https://www.ibm.com/docs/en/rational-clearcase/8.0.0?topic=rcgbs-derived-objects-configuration-records), to accelerate builds (largely C/C++ builds at the time) – VonC Jun 14 '21 at 13:31

1 Answers1

1

Note: I have documented the main difference between Git and ClearCase in "What are the basic clearcase concepts every developer should know?" back in 2009.

You do not "checkout" a branch.
You list a set of config select rules with version selectors, like:

element * CHECKEDOUT
element * .../mybranch/LATEST 
element * /main/LATEST –mkbranch branch-type-name

That will select any latest version on myBranch (unless said version is being modified, status "CHECKEDOUT").
Or, if there is no myBranch version yet for that particular element (file or folder), the latest of main (since every version starts with /main/0).

The problem with that model is in the branch path: you need to remember from which branch you started myBranch.
If it is from /main, the selection rules above are enough.
But if it starts from another_branch, that would be:

element * CHECKEDOUT
element * .../mybranch/LATEST 
element * .../another_branch/LATEST -mkbranch mybranch
element * /main/LATEST -mkbranch mybranch

The rules (for dynamic or snapshot views) are read from top to bottom: the first one applicable will be the one used by the view to display the file/folder.

Note: you cannot checkout just one file.
You have to checkout its parent folder (and parent/parent...) in order for said folder to display the right file list (from which you can then checkout the file).

That is very different from Git, obviously, which does not care about folder, only about content (tree content or file content/blob).

So you need a set of rules which will apply to the VOB elements, in order to see your single file (because that set of rule will have selected the right version of the parent folders, for you to access the right version of your file).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Appreciate the help - I gave your Basic Clearcase Concepts post a read and it really cleared up a lot of questions I had. Especially the file-centric part; seems like not a great way of handling commits. – blarglesz Jun 14 '21 at 13:19
  • @blarglesz ClearCase started with Atria in 1990 (https://en.wikipedia.org/wiki/Atria_Software). At the time, it was not a crazy idea... But it did not age well. At all. – VonC Jun 14 '21 at 13:26