ClearCase Common Workflow Example

Question

I am working with ClearCase and I am very new to the tool. I find it confusing and cumbersome compared to other source control, like git with svn, for example. I was wondering if someone could walk through a typical workflow. So right now we have a main integration stream, then a child stream on that, then from there child streams for each project.

Use Case 1:

I check in a file and want everyone to get changes. I have to first add to ClearCase or check in, then I have to deliver to each stream above me (twice), then I would create a baseline and do a rebase to cascade the changes back down. Is this correct?

Use Case 2:

If I forget what changes I made, is there a mechanism to see all the files I modified? and check them all in at once.

Use Case 3:

If I want to modify a file, do I always have to check it out?

Use Case 4:

If I move a file, must I remove it from clear case and then re-add it? Or what about if I just want to rename a package or file?

Use Case 5:

Right now I have a dynamic view on the main integration stream, then child views in between. If I am just working on one stream, is it necessary to have views on all the other streams?

I am just trying to use clear case effectively, but it seems to accomplish simple tasks, there is a lot of overhead. Can anyone give any tips or advice on how to simplify the experience?

Thanks

Answer 1

You can see the main differences between Git and ClearCase here, to get you started.

Use Case 1:

Yes, which is why it is advised to use one stream if possible, instead of the native "one stream per developer" model (that I denounced here)

Use Case 2:

You can use some commands based on lsco | ci, as in this answer.
I detail that approach in "Recursive checkin using Clearcase"

ct lsco -r -cvi -fmt "ci -nc \"%n\"\n" | ct
ct lsco -r -cvi -fmt "unco -rm %n\n" | ct

Use Case 3:

Yes, you need to checkout a file, before modification and checkin, unless you modify it directly in a snapshot view, as an hijacked file; or in a dynamic view as an eclipsed file.
See for instance "Eclipse not allowing to modify files without checkout in ClearCase" as an illustration of that issue.

Use Case 4:

cleartool mv will do that for you (as I mentioned here), but you need to checkout the parent folder first.

The directory where the element to be moved or renamed resides must be checked out. The destination directory must also be checked out; this directory may be the same as the source directory.

Use Case 5:

If I am just working on one stream, is it necessary to have views on all the other streams?

No, those views don't have to be started or even created.