ClearCase‎ > ‎UCMpedia‎ > ‎

Baseline


A baseline is essentially a time-line and from that perspective it's the closest equivalent to a commit as known from systems like Subversion, CVS, Bazaar, git and Mercurial. And then again - it's far from the same.

ClearCase doesn't track changes at repository level like the systems mentioned above. In ClearCase each individual file and directory has it's own individual version tree. The compelxity you get from that approach is ...simply overwhelming! In many situations it's not even especially useful and could just be disregarded as a different architectural approach to solving the same problem  - which in turn could trigger a general discussion about modern  VCS architecture - but we'll take that discussion elsewhere.

The point is that in everyday work it's often more useful to trace a repository state as opposed to an individual element state and the UCM baseline does exactly that.

A baseline is tied to both a stream and a UCM component - which in turn can be a rootless component and as a consequence the baseline is then really a composite baseline.

So the baselines are stable reference points and they are also used at the foundation of streams. What that means is that all streams have an off-set that is identified by a baseline. When you rebase a stream, what you do is actually that you change the streams foundation(!)

So what is inside a baseline, what's the stuff that it's made of? The answer is "activities" (and in this case more interestingly, the activities' change sets).

A baseline has a promotion level, by default UCM used the five predefined levels:
  • INITIAL (could also be regarded as undefined since this is the state that a baseline has until you explicitly change it to something else).
  • BUILD (used to identify the state that the baseline actually builds successfully)
  • TESTED (used to identify the state where the baslien, not only builds but also meets some imaginary level of validation or approval)
  • RELEASED (used to indicate that the content of this baseline was actually release from the project ad is used by others outside the project)
  • REJECTED (used to identify the fact that the baseline is crab and you should avoid it)
You have to posibility to go and change the five predefined promotion levels, you can rename, delete and create new levels in order to make the terms reflect how-you-work. But it turns out, that it's actually somthing that you can only do from a command line, so you'll need to script your way around it, and on top of that, you need to define the levels for each invidual UCM project you create, so in reallity it's probably most feasible to just put some meaningful interpretations into the five predefined ones and stay with those.

Comments