Configuration managers and other users may know the following situation:

You manage all your project assets in a central repository. As the project is progressed and the end of a milestone is coming, and you want to work in parallel, you have the following indecision: Whether to use the same repository for the next milestone, or open a new repository?

In this post I’m going to write my idea about this situation regarding ClearCase UCM.

In ClearCase UCM you have 2 kinds of repository: the physical (“VOB”) and the abstract (“UCM project”). In this post I refer to the abstract one. (Well, you may say that the UCM project is considered to physical also since its inrormation is written into the PVOB, but I assume you agree that it’s more abstract than physical )

Well, as you figure out from the post title, I support the first option, so here I write the reasons plus pros and cons.

• In case of using more than one component, it’s very recommended to use more than one project, since it enables us to define one component as Read/Write, and the other component as Read-Only (and vice-versa on the other project). This definition let us change The Read-only component to elder BaseLine if necessary.
• The GUI reason: The project hierarchy is much clearer when using the Project Explorer: there are separate rows and different icons for projects, integration streams and development streams. It may sound quite stupid, but it prevents accidents like mistaken delivery or rebase by the users!
• In ClearCase 2003.06 and above, there is a new option that lets us define the policies per-stream. Using it with sub-streams project may cause accidents.  When using multi-projects, it lets us define separate policies for every project, and enforce its policies automatically for all project’s streams.
• If you integrate your ClearCase UCM to ClearQuest, you can filter your ClearQuest records by the “UCM Project” field. It is much easier than filtering by sub-streams.
• If you use the “Composite Baseline” feature, managing the composite baseline and its dependencies is easier and more flexible by using multi-project option, rather than the sub-streams options.

Actually, Whatever a decision you take, in the backstage, there is no big difference between multi-projects or sub-streams: both are separate and parallel streams.