tags:

views:

117

answers:

3

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.

A: 

Of course.

I don't know your ClearCase version and operating system, so you'd better to start here - check for "Developing Software": ftp://ftp.software.ibm.com/software/rational/docs/documentation/manuals/clearcase.jsp

Regards, Tamir Gefen

GoMidjets - ClearCase Plug-ins

Tamir Gefen
A: 

The main thing you need to know is that how you use SVN today, is called snapshot views in clearcase. For the rest clearcase has loads and loads of features like dynamic views, activities, derived objects and its own make system. Nobody used these features at the company I worked for that made a global choice for clearcase. O yeah, and it does not really work if the server you connect to is not in your office.

Most clearcase material I've seen concentrates on all these other features, so, I'd read them with some healthy scepticism.

jdv
Yup, I know CC has snapshot view and dynamic view.
shiouming
+3  A: 

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"
VonC
I just come across integration stream and development stream. I understood their difference in terms of use case, but wondering if they differ in terms of technical implementation within ClearCase. Take SVN as example, we can have version branches (i.e. 2.x, 3.x) and developer branches, but SVN treats version branch and developer branch essentially the same.
shiouming
@shiouming : for SVN, both version branches and dev branches are just directories with cheap copy. For CC, Int stream and dev stream are both streams (list of labels): they play the role you want them to play. The only difference is: when you create a UCM project, you need at least one stream (called by convention " Integration" stream), and then you can (but are not obliged to) create one or several sub-streams ("dev" streams).
VonC