Quick way for SVN user to learn ClearCase

clearcase

So far I've been using SVN, and now is in need to pick up ClearCase quickly, from developer's perspective. Is there any good resource for this? Thanks.

— add on —
Is there a map between SVN's concepts/terminologies (i.e. repository, working copy, trunk, branch, tag, checkout, commit, update, revert) with CC's? Base on initial reading I came out with the following.

Repository => VOB?
Working copy => Snapshot view?
Trunk => ??
Branch => Integration stream? development stream?
Tag => Label? Baseline?
Checkout from repo as working copy => Checkout from VOB as snapshot view?
Commit from working copy into repo => Checkin from snapshot view into VOB?
Update => Rebase?
Revert => ??
?? => Deliver

AFAIK CC has its own unique concepts, thus I can't tell the nearest map.

Best Answer

You can start by reading my SO answers:

The two main differences you need to be aware of is:

  • ClearCase is file-centric, not repository centric, meaning you get read-only files you need to checkout one-by-one to be able to modify, (and you "commit" (checkin) one by one as well): no global workspace revision here

  • ClearCase consider branching as true metadata, and not as a "directory" with a cheap copy in it: there is non "directory" with the name of a branch in it.

That being said, quickly:

  • Repository => VOB:
    Yes: VOB is just another term for repo (Versioned Object base). It is not a SQL database, but an old Atria flat files base.

  • Working copy => Snapshot view?
    Snapshot view is the closest access mechanism from a working copy, since it copies files on your hard drive.
    Dynamic view achieve the same access to a working copy... without copying anything on your hard drive, which is interesting for quick consultation purpose.

  • Trunk => ??
    "main": that is the main branch in ClearCase (every element -- file or directory -- in ClearCase has at least one version on "main"), but actually there is no trunk except the one branch you choose as trunk.

  • Branch => Integration stream? development stream?
    A stream is not a branch. It is a metadata with the list of labels (baselines) you need to work. At that is, only if you chooses to use UCM. Otherwise, a branch is any branch you can create without UCM (mkbranch myBranch).
    A stream can serve as a pattern to create a branch named after it: any checkout you make within an UCM view (a view configured automatically after a Stream) will create a branch named after its stream.

  • Tag => Label? Baseline?
    First a tag is not a directory with a cheap copy like UCM.
    It is a label applied on any version you need to be referenced by it.
    The difference between a label (non-UCM) and a baseline (UCM) is that a Baseline is a label applied on all files of a (UCM) component (group of files), whereas a label can be applied on any element of your choice, like only a subset of a given group of file.

  • Checkout from repo as working copy => Checkout from VOB as snapshot view?
    Almost, but the right term for snapshot view is "update".
    For a dynamic view, you don't even need an update (or svn checkout), since the view is ... dynamic: you just see the right working copy through the network instantly. It is just another access mechanism.

  • Commit from working copy into repo => Checkin from snapshot view into VOB?
    Not quite, since a commit will concern all modified files, while a checkin will be file-by-file (even though ClearCase 7.1.1 has introduced the notion of "atomic checkin": see checkin man page).

  • Update => Rebase?
    Nope: means update in snapshot view (an nothing in dynamic view since it is dynamic: any changes made in another view with similar selection rule will be visible instantly in your view)
    Rebase is an UCM merge being done being a branch from a parent stream to a branch from a child stream. In the end, it is just a merge.

  • Revert => ??
    Not trivial... It is a substractive merge.

  • ?? => Deliver
    Deliver and Rebase are just merges between branch "source" and branch "destination":
    The only advantage being you can "see" your merge workflow in advance be defineing a hierarchy of streams (which are nothing but a list of labels), knowing that any merge between:

    • branch from a child stream to a parent stream will be a "deliver"
    • branch from a parent stream to a child stream will be a "rebase"
Related Topic