How to provide the same function in StarTeam that users are able to get from ClearCase config specs



How to provide the same function in StarTeam that users are able to get from ClearCase config specs



The functionality provided by a ClearCase “config spec” is a subset of the functionality provided with StarTeam views. It is easy to share items at different configurations (times, labels) into a new view. Therefore it is easy to create a view that consists of specific releases of "components", including historic revisions that cannot be modified (pinned, Branch-On-Change=false) and revisions that can be modified (Branch-On-Change =true). Since StarTeam views are server-side and persistent, they are in a sense more useful than ClearCase “config specs”.


Here’s an overview of the procedure to create a StarTeam view that is the equivalent to a ClearCase “config spec”:

1) Create an empty child variant view (not a blank view). The easiest way to create an empty variant view is:

- Click View -> Properties on the parent view and note the date in the creation timestamp.

- Start the View -> New wizard. When you get to the "Specify Configuration" page, select a date prior to the creation date of the parent view. The CPC will complain about the date being older than the parent view and automatically adjust it to the creation timestamp of the parent view.

- Finish the wizard and the new view will be empty except for the root folder.

2) Open the parent view in a second window and select Window -> Tile Horizontal so that both views are visible.

3) Select the parent view and configure it to a label or timestamp of something you use to identify the versions you want to start from (i.e. View -> Select Configuration).

4) In the parent view, select the folders and/or items to be shared, hold down the Ctrl key, drag them to the child view, and drop them where they should be shared. The CPC will display a share confirmation window. The newly-shared items will be configured to the same timestamp as they have in the parent view. For example, if the parent view was configured to a label "Build 103", which caused an item to be configured to the timestamp 1/1/2009 at noon, then that item will be pinned to 1/1/2009 at noon in the child view. For branchable items, the new child shares will normally also be marked with Branch-On-Change = true, based on the child view property "Set items shared into view to branch on change".

5) If some items in the child view are never to be modified, the Branch-On-Change flag should be turned off. This can be done in bulk by multi-selecting those items and selecting Advanced -> Behavior.

6) Repeat steps 3 through 5 for each component to be shared, using the appropriate label or timestamp in the parent view each time.

This quick summary is oversimplified in several ways. For example, the child view probably needs a slightly different folder structure than the parent view. In which case some folders would need to be created anew while others are shared. This article is intended to illustrate the general concept.

If this is a procedure used a lot, you may want to write an SDK application that creates custom child views using a configuration file. If the developers using this procedure have previously used ClearCase then such a configuration file would look much like the ClearCase "config specs" they used before.

Old KB# 30018
Comment List