ClearCase UCM: WHAT IS

I went through the Source Control HOWTO some days ago. Almost all the chapters till now have information targetted at beginners. However, the fourth discusses some behind the scenes issues too, about how versions are retrieved from deltas etc. Overall a good guide that freshers should read (I remember my early days in firstRain and shudder :))

Well things did improve after the early days and we got around to using CVS and here at IBM Rational I have been using (no points for guessing) ClearCase.

We are using the UCM(Unified Change Management) partially (Partially because UCM can also integrate with ClearQuest so that there is a relation between the bugs/tasks and your code changes which we are not using for some strange reason)

If you join a team which works with UCM you can have a pretty clueless first few days because UCM abstracts out a lot of the source control activities. I am still not sure about some :). The following is how I understand CC by equating the different CC terms to basic SCM operations (mostly in terms of what I know from CVS usage).

1. Project: A project in UCM translates to a branch in CVS. So when you start with a new project you create the main trunk with some set of files and then as the project evolves you add/delete/modify files on the trunk.
2. Streams: Again streams map to branches. There are two kinds of streams Integration and Development. Every project has a single integration stream where all the developers integrate their work. An integration stream is a branch of the trunk. A project can have multiple development streams. Many developers can have many development streams. A development stream is a branch from the project's integration stream. One develops everything on the development stream. So in CVS terms it is like having at least one separate branch per developer per project. Thus you are free to checkin as many intermediate versions of your work as you like without affecting others.
3. Activities: CC has the checkout-edit-checkin model as opposed to the edit-merge-commit model of CVS. This brings us to "Activities". When you checkout you can associate the checkout to an "activity". An activity has a name and you can associate multiple checkouts of the same file or multiple checkouts of a set of files with an activity. Later you can view an activity and examine the change set associated. e.g. To fix a bug you create an activity called "Fix bugno" and associate it with all the files that you checkout for it. This is the equivalent of putting up a patch manually on a bug. Instead of the bug and you doing the job you let the source control system to do the tracking. Plus this has the advantage that you can view differences between multiple versions of the same file during the course of the activity.
4. Deliver and rebase: Occasionally you want to merge your changes back to the integration stream or merge the latest from the integration stream to your development stream. These actions are called "deliver" and "rebase" repectively. This is just like normal merging from one branch to the other in CVS but devoid of the pain of labeling each time before doing the merge. Clearcase does the job of creating an activity and maintaining the change set for the merge and also remembers the points from which you have merged changes on both branches. One can also selectively merge changes by delivering only those activities that you want (provided there is no dependency between the activities)
5. Views: A view in CC is your local CVS tree or working area or sandbox. Views can be snapshot or dynamic. Snapshot views are like a CVS tree which you need to update explicitly to get the latest changes. A dynamic view resides on the server and any changes that go into it are visible to you immediately. CC recommends using a dynamic view for the integration stream and a snapshot view for the development stream. Some people actually like dynamic views a lot and use it for development too. My personal opinion differs and I think it is not a good idea. CC implements a file system for achieving dynamic views and in effect on windows it mounts a folder from the server. This causes the builds to be slow..maybe it can be speeded up with some tuning parameters for the MVFS file system that CC uses but I haven't tried that..but regardless, I think it is not such a great idea. It increases your dependence on the network and you can't work offline.
   
6. Baselines: Baselines are like tags or labels in CVS.(I suspect they are something more too but for the scope of this discussion this idea suffices)
   
7. Policies: In UCM one can specify project policies. One example which the manual gives is enforcement of the policy that a developer should rebase to the latest baseline fro m the integration stream and thus do most of the merging work in his development view. This saves you from the scenario where the developer is locking up the integration view files for complex merging. If the user tries to violate a policy clearcase shouts. In CVS one has to merge in the local tree by default if the local version is out of date. But then there are other policies that one can enforce too like allowing/disallowing delivery across projects etc.
8. Parallel development: After some time you reach a point where you want to fork off on a release branch. In CVS one would create a branch. In CC you create a new project and "seed" it from some baseline of the project from where you find it best to fork. So now you can develop parallelly on the release project and the project from where you forked (mostly the main project). You can then later choose to merge changes from your release branch on to the trunk project by "delivering a baseline" across projects. For the other way round you can rebase the release projects integration view from the required baseline on the trunk but this is a very unlikely scenario. The point that I am trying to make here is that just as deliver and rebase applies for integration and development streams it can also be used for integration streams across projects. As already described a project maps to a branch and so do the streams so the basic operation of merging applies to both.