ClearCase‎ > ‎UCMpedia‎ > ‎


A ClearCase UCM Activity is a small object that basically consists of 
  • An ID
  • A headline (title)
  • A change set
Despite the simplicity of an Activity it's a very fundamental part of the UCM approach. In order to do anything (in terms of changes) you'll need to attach those changes to an activity.

Activities are attached to (belongs to) streams.

An activity can only be attached to one stream.

A stream is therefore logically a container for activities and can (should!) be used to group related activities to each other.

A view can have an activity "set" to be the default activity, meaning that if you don't explicitly tell differently checkouts will be done in relation to the default activity.

ClearCase uses two special variants of activities to accomplish behind-the-scene tasks. Since UCM strictly enforces that no checkouts can be done unless they are related to an activity, then consequently, when rebase or deliver operations are carried out, there will have to be activities involved! right?

For the purpose of rebase and deliver ClearCase creates activities that are prefixed with either rebase or deliver. These two special variants of activities have the additional ability to be composite activities, that is; they can have nested or contributing activities.

Activities are also fundamentally the stuff the baselines are made of. Activities are also the chunks of work that you deliver, when you start a deliver operation (well you can also deliver a baseline, but since a baseline is made up of activities, it's essentially the same).

The fact that you are delivering activities when you deliver is interesting. It means that when you initialize the deliver you are prompted to choose which of the activities you actually which to deliver, you simply check the ones that apply.

Well "Keep dreaming honey child!".

This is a highly conceptual choice and in real-life you'll often realize, that if you do cho0se to use this option and only check some of the activities that are currently attached to the stream, you'll get the message from ClearCase that the activities you have chosen have dependencies to activities you haven't chosen and consequently you end up with only two (equally ugly) options to chose from; all or noting.

So, what went wong?

It turns out that conceptually UCM has a very fundamental principle when it comes to how activities should be used, it's not strictly enforced anywhere, but if you vilolate the principle, then you basically abuse UCM ...and consequences are ugly!

Give the following two statements some thought:
  1. Only activities that are closely related should go onto the same stream.
  2. Streams should be closed for further use as soon as their original purpose is fulfilled.
You should adapt to these doctrines in order to get the best out of UCM. If you fight it you're not entirely exploiting the features that you paid so generously for!

And basically, the only argument I've ever recorded against this approach is that creating new streams and views (especially snapshot views) are tiresome, boring and a waste of time. And it's quite easy to argue against. It's really a trade-off and the time you spend keeping your working environment tidy pays back when you're done developing and focus switches to validation, quality assurance, delivering, promotion, rebase, integration etc....

Do The Right Thing

Only activities that are closely related should go onto the same stream.

Streams should be closed for further use as soon as their original purpose is fulfilled.