CM ClearCase > ClearCasePages > ClearCaseFAQs ClearCaseUnifiedChangeManagement

ClearCase Unified Change Management


[see other ClearCasePages on this CMWiki]

Questions (Generated automatically from sections below)

(To add a question, just add an entry to the answers wink )

Answers

1. Process questions

1.1. Is UCM a tool or a process model?

Although opinions may differ on this, I generally prefer to see UCM as a process model for making changes in a controlled manner. This model looks about like this:

  • Developer:
    • Get or update workspace
    • Find work order
    • Make changes
    • Deliver changes

  • Integrator/Tester:
    • Determine quality of changes
    • If not OK: make new work order to correct it
    • Else: Make changes available
    • Make baseline

  • Project manager:
    • Schedule work and assign work orders
    • Monitor progress of work orders
    • Release product baseline when work is completed

It has been implemented on top of ClearCase and ClearQuest, but it may be applied to any tool that supports concepts like configurations, changes to configurations, workspaces, work orders and baselines.

On the other hand, many users regard UCM merely as a tool extension of ClearCase, implementing the integration of ClearCase and ClearQuest. Yes, you can use UCM to make ClearCase more "wizard-driven" and easier to use for novice users, you can use UCM streams to manage branches, you can use UCM to control change sets and you can use it to manage component development. In other words, you can use the UCM features without using the UCM model.

But keep in mind that UCM is not designed to be fully flexible to just any process model. If you need ClearCase to behave exactly to your wishes, you may have to accept that you have to implement the triggers, rappers and commandscripts yourself and refrain from UCM.

1.2. Is it possible that more than one developer deliver to the same stream simultaneously?

It depends:

  • It is not possible to perform multiple delivers to the same view. Every deliver needs a current "deliver" activity in the integration view. One view only allows one current activity.
  • It is not possible to perform multiple delivers to the same stream using different views when delivered elements are checked out. A deliver checks out files, so the next deliver can not check out the same elements again.
  • It is possible to perform multiple delivers to the same stream using different views as long as different elements are delivered.

To check if a deliver is ongoing, do the following on the development streams: 

      cleartool deliver -status

To be sure, you may have to check any stream that is capable of delivering to the integration stream. With inter-project delivery, this could become a nuisance to do. Instead you could perform the following:

  1. Check the current activity in the integration view
  2. If that is a deliver-activity, you could check the status of the deliver on the stream that is doing the deliver-activity.

It is best to automate this check by creating a script. 

      # get the last activity, and if it is a delivery, get the development stream;
      ( $activity ) = reverse grep /^deliver/, `cleartool lsactivity -short -in $ENV{'CLEARCASE_STREAM'}`;
      exit 0 unless $activity =~ /deliver\.([^.]+)\..+/;
      $dstream = $1;

      # get the delivery status of the development stream embedded in the delivery activity name
      $pvob = $ENV{'CLEARCASE_PROJECT'}; $pvob =~ s/^.*\@//;
      $status = `cleartool deliver -status -stream $dstream\@$pvob`;

      # if activity not in status output, then no delivery in progress
      exit 0 unless $status =~ /$activity/;

      # inform the user of a delivery and error exit
      print "A deliver is already in progress from '$dstream'. Please try again later.\n";
      exit 1;

1.3. How to implement a "pull" delivery?

Lock the integration stream for all users except the integrator. When a user is ready, the integrator performs the deliver on behalf of the developer. In this case, developers do not need to have an integration view.

1.4. How is the integration with ClearQuest a benefit?

When not having the integration with ClearQuest in UCM, all activities are merely the identification to a change set, not real activities. With ClearQuest, activities follow the state transitions defined in ClearQuest and additional information may be added to an activity.

As a consequence, the My Activities list will only show that are actually in the work-in-progress state when intragrting with ClearQuest. Submitted or Completed activities are invisible.

1.5. How to avoid evil twins?

Although you can prevent evil twins by triggers, it sometimes happens that two different developers have to make new files in the same (new) directory. The UCM way is:

  1. Create new directory in a (private) development stream
  2. Deliver the activity to the integration stream
  3. Make a baseline in the integration stream
  4. Recommend the baseline
  5. Rebase the development stream of other developers

This is a long way of doing it, which may hamper normal integration work, just to propagate a simple change such as a new directory. A shorter way is:

  1. Create new directory in a (private) development stream in an activity that does not contain any other changes
  2. Deliver this activity directly ( deliver to alternative stream) to the other development stream

Other information on evil twins can be found on the BasicClearCase page.

1.6. How to organise UCM MultiSite?

When not using the integration with ClearQuest, UCM MultiSite involves replicating the PVob and all component Vobs that you need at the remote sites using ClearCase MultiSite?. Since all developers use the PVob, you need MultiSite licenses for every user in every project within the PVob (*), even when projects do not use the component VOBs that are replicated.

When using the integration with ClearQuest, you need to replicate the ClearQuest database using ClearQuest MultiSite only to the remote sites using projects that are ClearQuest enabled.

(*) Because of floating licenses, you may not need 100% coverage of licenses to users.

1.7. What is the difference between a (base ClearCase) Vob and a UCM component-Vob?

Under base ClearCase, you can use the UCM component-Vobs (single component or multi-component) just as ordinary Vobs. You can create branches, elements, versions, labels, etcetera. The PVob serves as the admin-Vob.

Under UCM, you do not use the base ClearCase Vobs unless they are "componentized" (i.e. associated with the PVob), mainly because you do not specify the config-spec yourself; it is generated by UCM. To access a base ClearCase Vob, add your own config-spec rules to the custom section in the (UCM generated) config-spec.

Please note that UCM Vobs are automatically mounted when starting a UCM view. Base ClearCase Vobs must be mounted manually.

1.8. Can you integrate UCM with MS-Project to manage activities?

Yes, you can. Rational provides ClearQuest Tracker with ClearQuest that allows one-to-one synchronization of tasks in MS-Project with records in ClearQuest. When those records are of record type BaseCMActivity or Defect, UCM can also use them.

1.9. How to start a new project as successor of an existing project?

This seems like a silly question at first, because the UCM manual clearly explains how to start a new project. In essence it involves 2 parts:

  • Make a new UCM project
  • Select a stream of an existing project

Although it is not incorrect to do it like this, you are actually creating sub-projects. You do not have to specify a baseline in the stream because UCM automatically takes the latest baseline in the stream. However, with this approach the branch name extends every time you create a new project based on an old one, for example: 

      /main/R1.0_integration
      /main/R1.0_integration/R1.0maint_integration
      /main/R1.0_integration/R2.0_integration
      /main/R1.0_integration/R2.0_integration/R2.0maint_integration
      /main/R1.0_integration/R2.0_integration/R2.1_integration
      /main/R1.0_integration/R2.0_integration/R2.1_integration/R2.2_integration
      /main/R1.0_integration/R2.0_integration/R2.1_integration/R2.2_integration/R3.0_integration

As many dialogue windows in the UCM GUIs have a limited (and often fixed) width, you would not like very long branch names. A better approach might be the Mainline Project methodology.

1.10. What is the Mainline Project methodology (compared to Cascaded Projects)?

1.10.1 Cascading projects

You can create a new project as a successor of a previous by using a baseline of a previous project as the foundation for the new project. The resulting branching structure will look like this. In this example, PROJ02 even continues after PROJ03 has started. PROJ03 rebases to the new baselines of PROJ02 when they become available. 

      main
        |
        0 "INITIAL"
         \_____
               |
             PROJ01
               |
               ' "REL1"
                \_____
                      |
                    PROJ02
                      |
                      | "BUILD231"
                      |\___________
                      |            |
                      |         PROJ03
                      |            |
              "REL 2" '--rebase--> |
                                   :

This way branch names will grow, and grow, and grow ... until you run into the maximum branchname length that ClearCase can handle. 

      /main
      /main/PROJ01
      /main/PROJ01/PROJ02
      /main/PROJ01/PROJ02/PROJ03
      :

1.10.2 Projects from scratch

To avoid cascading projects, you could decide to start all projects from scratch. Instead of using an existing baseline as the project's foundation, use the INITIAL baseline of components. If you need the contents of an existing project, you should deliver it to your new project. 

      main
        |
        0 "INITIAL"
         \_________________________________________________
          \                                                |
           \_____________________________                PROJ01
            \                            |                 |
             \___________              PROJ02 <--deliver---' "REL1"
                         |               |
                      PROJ03 <--deliver--' "REL2"
                         :

The branches will not grow indefinitely: 

      /main
      /main/PROJ01
      /main/PROJ02
      /main/PROJ03
      :

The disadvantage of starting with an empty project every time is that you will deliver the complete contents of a previous project, for every project again. This is an inefficient use of branching since you are duplicating a lot of data.

1.10.3 Mainline project

The next alternative is to use a mainline project. A mainline project is created as a foundation for all new projects. This is congruous to the Base ClearCase process of merging version specific integration branches to the /main branch, then creating new integration branches.

You can read more in the ClearCase Managing Software Projects manual in section 9.3 (from the 2002.05.00 documentation set).

The picture will look like this: 

      main
        0 "INITIAL"
         \______________________________
                    |                   |
                 MAINPROJ             PROJ01
                    |                   |
                    | <------deliver----'
                    1 "REL1"
                    |\__________________
                    |                   |
                    |                 PROJ02
                    | <------deliver----'
                    2 "REL2"
                    |\__________________
                    |                   |
                    |                 PROJ03
                    :                   :

resulting in branch names like this: 

      /main
      /main/MAINPROJ/PROJ01
      /main/MAINPROJ/PROJ02
      /main/MAINPROJ/PROJ03
      :

And even if a previous project has not finished yet when you need to start a new project from the latest baseline in the main project and deliver the baseline of you running project to the new project. DO NOT (!!) rebase to the a baseline from the running project because that way your new project will cascade from the running project, instead of from the mainline project.

If the running project finishes and delivers its final baseline to the mainline project, you can rebase your new project to this new baseline (from the mainline project). It looks like this: 

      main
        |
        0 "INITIAL"
         \__________________________________
                        |                   |
                     MAINPROJ             PROJ01
                        |                   |
                        | <------deliver----'
                        1 "REL1"
                       /|\__________________
                      / |                   |
                     /  |                 PROJ02
            ________/   |                   |
           |            |                   |
         PROJ03         |                   |
           | <-------------------deliver----| "BUILD231"
           |            |                   |
           |            |                   |
           |            | <------deliver----'
           |            2 "REL2"
           | <--rebase--|
           |            |
           |            |
           '--deliver-->|
                        3 "REL3"
                        :

If you which, you can make sub-projects within each of the projects that will cascade. But these sub-projects should not deliver to the mainline project themselves. Instead, they deliver to their parent project.

Here are a set of steps to migrate to a Mainline Project methodology if you already have a running project:

  1. Make a baseline in your running project
  2. Make a new UCM project, the mainline project
  3. Select the baseline from your existing project as its foundation
  4. IMPORTANT: replace the baseline for all components (in your mainline project) by the _INITIAL baseline
  5. Mark all components as modifiable that are also modifiable in your running project
  6. Deliver the baseline from the running project to the integration stream of the mainline project
  7. Make baseline in the mainline project

When your running projects finishes, deliver the final baseline to your mainline project and make a baseline in your mainline project. This will (or may) serve as starting point for new projects.

Note that with the mainline project methodology, it is also easy to create maintenance projects (or projects that make patches) of old releases. Don't deliver those maintenance projects to the mainline.

1.11. How to deal with UCM on multiple sites?

The basic concept of ClearCase Multisite is based on two principles:

  • Replication of databases (Vobs), to make identical copies at every site
  • Mastership of objects, to avoid simultaneous updates at (exactly) the same object

When replicating UCM databases, at least the Project VOB (PVOB) must be replicated, because it contains the UCM specific objects that are not supported for base ClearCase. Note that this implies that all users accessing the PVOB require a MultiSite license.

But due to the way UCM is implemented upon ClearCase, mastership is often a source of trouble in a multiple site configurations. Therefore is it advisable to work on a single site within a single UCM project. Other UCM projects within the same PVOB may be worked on at another site, but not on multiple sites. The only operation that is expressly implemented for multiple sites within the same UCM project is deliver. Operations like rebase, join project and even make view are likely to be cumbersome when it involves multiple site mastership.

Please help other UCM users and add your knowledge here about how to deal with UCM on multiple sites.

1.12. How to deal with an instable (frequently changing) architectures?

An instable architecture means that you regularly have to create new components and delete obsolete ones. Since removing a component from UCM (i.e. from a PVOB in UCM) is seriously troublesome, it is better not to remove components. If you have an instable architecture, you may consider the following strategy, or your own variation on this theme.

Step 1: Make a single-component System

Define a PVOB with a single UCM component, for example "The_System". It's your choice to put the component in the PVOB or a separate VOB. For every 'component' that may be a candidate for a UCM component, define a sub-directory in "The_System".

In the UCM project you define, you only have one UCM component (i.e. "The_System") which is modifiable. When you make a baseline, it is a baseline of "The_System". In other words, you can not baseline a 'component' individually.

Step 2: Add more components

If you want to add more 'components', just create new sub-directories in "The_System".

Step 3: Delete component

If you want to delete one of your components, just remove it from "The_System" with cleartool rmname or using the ClearCase Explorer.

Step 4: Extract permanent component

When you discover that one of your 'components' becomes permanent, meaning that you are sure it does not have to be deleted anymore, do this:

  1. make a baseline of "The_System"
  2. make a new UCM component in the PVOB
  3. make a project containing "The_System" and the new UCM component
  4. copy the subdirectory from "The_System" into the new UCM component
  5. add the copied files and directories to source control
  6. delete the old component from "The_System" using cleartool rmname
  7. create a symbolic link ( cleartool ln -s) with the name of the old component in "The_System" that points to the newly created UCM component
  8. make a baseline in the integration stream, which contains "TheSystem" and the new UCM component

This way, the directory structure in "The_System" remains in tact so your build will probably still run, but the component is a separate UCM component. From this day on, the new component can be baselined individually, can be made modifiable / readonly in a project individually and can be included/excluded from a project individually. -- FrankSchophuizen? - 12 Apr 2003

1.13. Can you deliver an activity multiple times?

Yes, you can.

With ClearQuest integration new changes can be added to an activity and the activity can be delivered as long as the activity is in an active state. State changes have to be made in ClearQuest to unless you either manually change the state, or set a policy or trigger to propagate the state, an activity can be delivered.

Without ClearQuest integration an activity does not have a state model as with ClearQuest integration. Thus new changes can always be added and the activity can always be delivered.

Of course, if you lock the activity no new changes can be added.

1.14. How to work with composite baselines?


This section is a bit scattered. In due time, I will try to make it a consistent description. For now, please add your ideas and experience that may help us understand the practical use (and needs in case of limitations) of composite baselines.

If you have one rootless component called "TheSystem", you can start every project with the baseline "TheSystem_INITIAL" and create a completely different component dependency tree for every project, without needing a new (rootless) component. There is not need to create a new component for every project, such as "SystemA_Rel1.0", "SystemA_Rel2.0" or "SystemB_Rel1.0".

Similar for non-rootless components (with VOB storage), e.g. the component ProjectDocumentation. -- FrankSchophuizen? - 08 Dec 2004

We run in some trouble having components with code and dependencies to other components. In the first case it would have been better to create a larger components with code of both or in the second case we were not able to tear of dependencies using the component at an other place. So now we create an component without a vob (rootless component) for each group of projects and make all components in our project depend on this component. Every new baseline in our project's streams will also create a new baseline in this rootless component. Now it is easy to browse the baselise of this rootless component and see all involved component baselines in the members property. Follow up strams and projects will refer only to this composite baseline from this rootless component. If we use one of our components in another project we can get baselines of it without dependencies. -- HomagSWP? - 29 Sep 2004

I have tried to use composite baselines in a project but I did not manage to find a satisfactory approach dealing with them. The problem I ran into was that projects were aiming for a (final) product release, but in the meantime were also releasing (reusable) components. In addition, the composition of components in a baseline may vary during the course of the projects. I have the impression this indicates that may approach is not right. Please tell about your experience. -- FrankSchophuizen? - 03 Dec 2003

1.15. How to work with baseline promotion levels?

UCM consists of two main workflow models:

  • Change model (using stream interaction)
  • Promotion model (using baseline levels)

The change process model basically consists of these steps:

  1. Work on activities (developer)
  2. Deliver activities to the integrator (developer)
  3. Make baseline (integrator)
  4. Verify (usually build & test) the baseline (integrator)
  5. Recommend the baseline (integrator)
  6. Rebase to the recommended baseline (developer)
  7. Back to first step...

From this you see that the baseline promotion level is not really relevant. However (part of) the promotion model may be used to determine the recommendation decision.

For the promotion model, the organization defines for every baseline level a number of criteria that need to be satisfied before the baseline may be promoted to that level. For example, a baseline must pass a build and a smoke test before it is promoted to BUILT. Typically, recommendation of a baseline is part of the promotion model but UCM does not necessary require that, meaning that a baseline at INITIAL level can be recommended, if that's what the organization defines.

So for every baseline level it is defined:

  • What criteria must be satisfied before promoting to the next level
  • Who is responsible for checking the criteria (e.g. an independent QA group)
  • When the criteria are checked (e.g. by email notification or by frequently polling for new baselines at a certain level)
  • How the criteria are checked (e.g. by performing defined tests or inspections)
  • etc.

Not all baselines need to pass through all baseline levels. For example, promotion until the recommendation criteria are met may be enough when the intent is to allow distribution of a baseline to other developers (rebase). But if the intent is to release a baseline, all promotions have to be passed until the released level (typically RELEASED)

Note that the promotion levels are defined per PVob. This means that all components (or, if you like, all projects) within the PVob follow the same promotion model.

1.16 What is the difference between a stream and a branch?

A stream is a configuration in UCM: a collection of read-only and modifiable components, component baselines and activities containing changes made to the components. It provides the data that is needed to work on the configuration, such as a branchtype and a config-spec.

A branch is the implementation to store the versions of a particular element in a ClearCase VOB. Whenever a change is made, the resulting (new) element version is put in a branch and it is tracked an activity.

1.17 What is the difference between a stream and a view?

A stream is stored in VOBs. The element versions of a stream are stored in branches which are stored in VOBs. The metadata of a stream is stored in the Project VOB (PVOB). As with base ClearCase, one needs a view to access the element versions.

A view is the implementation of a file system to access the element versions of a stream. A UCM view always provides access to the LATEST version created on the stream, or (of no version has been created) the version of the foundation baseline. Views also provide a private storage for intermediate and temporary files and build results.

Views are intended to be temporarily, so they may be removed. You will not lose the data stored in the VOB. The streams however should not be removed because that will destroy the data in the VOBs. UCM goes into great length to make it difficult to remove a stream once it contains changes.

1.18 What is the difference between a baseline and a label?

1.19 What is the difference between an integration stream and a development stream?

2. Technical questions

2.1. How to create a component in a multi-component Vob?

It is not possible to do this on the GUI (v2002.05). Perform the following in a non-UCM view with a default config-spec: 

      cd M:\MyView\OurMulticomponentVob
      cleartool setcs -default
      cleartool mkcomp -root NewComponent NewComponent@\OurPVob

Note that this just makes the component. Your project doesn't see it nor is there any streams associated with the new component yet. To make this new empty component visible, Starting with the appropriate project's integration stream, select it's properties, add the new component, pick "show all streams", and the initial baseline should show up. Select it, and it should become part of the project. Then recommend that baseline. then rebase it to the other streams. Once done, all views for those streams need to be resync'd.

In v2003.06, the GUI of the Project Explorer has been extended to make components in a multi-component Vob. There are two ways to do that:

  • Make an empty component using the Project Explorer (easier said than done)
  • Import existing (base ClearCase) elements into UCM, using the following procedure:
    1. Make a new directory or move an existing directory in the Vob root directory.
    2. Move all elements into this directory that need to be imported in UCM
    3. Label this directory and all elements below it
    4. Import this directory using the Project Explorer
    5. Import the label using the Project Explorer

WARNING 1: After importing a Vob directory into UCM, it becomes a component and thus it will not be possible anymore to use cleartool mv in a non-UCM view on the elements, in any (UCM or non-UCM) branch. This implies that moving and renaming is only possible within UCM.

WARNING 2: When moving an existing directory in the Vob root directory, importing this directory will fail when any element version reachable through the version tree and/or directory tree underneath is already componentised for a different component. -- FrankSchophuizen - 30 Oct 2006

2.2. How to remove a component from a multi-component Vob?

  1. Remove the component from all projects. (That's easier said than done!)
  2. Remove the branch of the integration streams
  3. Remove all elements from the lost+found folder
  4. Use the cleartool rmcomp command to remove the component

Please note that it is very likely that remnants of elements or branches remain in the component. As long as that is the case, UCM will refuse to remove the component (with rmcomp). It may be quite hard to remove everything from a component.

2.3. How to remove a component from a project?

This is easier said than done, but basically you have to perform the following steps:

  1. Remove the component from the recommended baseline list
  2. Remove the component from all streams in the project
  3. Remove the foundation baseline of the component from the integration stream
  4. And finally, remove the component from the project

Removing (the baseline of) a component from a stream, you must rebase the stream: 

      cleartool rebase -dbaseline MyBaseline@\OurPvob
      cleartool rebase -complete

UCM will probably refuse because changes have been made in the stream. So before removing the baseline, you first must remove the changes you made on the component in the stream. If you made only changes to the component in this project, you may use rmelement and remove all versions of an element with a single stroke. Otherwise, you have the dreadful job of remove only the versions you want to get rid of with rmversion. In any case, do not use rmname because that will not physically remove versions or elements.

One way of finding all changes is by listing the change set of the activities in the stream, with the command: 

      cleartool lsactivity -long -cview

Make sure you also check the lost+found directory to be emptied. After you have removed all versions of elements in the component for all (integration and development) streams of the project, there is still one thing left behind: the branch of the component root directory. Although you should not remove the component rootdirectory itself, you must remove the branch of the stream. 

      cd MyComponent
      cleartool lsvtree MyComponent
      cleartool rmbranch BranchOfTheIntegrationStream

Now, you have removed all changes made to the stream and you can safely remove the component from the streams and then from the project: 

      cleartool rebase -dbaseline MyBaseline@\OutPvob
      cleartool rebase -complete
      cleartool chproject -dmodcomp MyComponent@\OurPvob

2.4. How to remove a single component VOB from a PVob?

First remove the component from PVOB, e.g.: 
   cleartool rmcomp BNS_App_Common_bin@/vobs/Intralink_pvob
   Remove component "BNS_App_Common_bin@/vobs/Intralink_pvob"?  [no] y
   Removed component "BNS_App_Common_bin@/vobs/Intralink_pvob".
Then remove the component VOB directory, e.g. 
   cleartool rmelem BNS_App_Common_bin

2.5. How to hide components in a view that are not in a project's configuration?

  • A components in a single-component VOB can only be hidden by unmounting the VOB
  • Components in a multi-component VOB can be hidden by adding the following line to the custom section in the cOnfig-spec for every multi-component VOB: 

      element /VobName/lost+found /main/0
      element /VobName/* -none

For all components which are within the configuration setting of the stream, UCM already has specific config-spec lines that make them visible.

2.6. How to create a composite baseline?

There are basically two ways:

  • Composite baseline of the LATEST element versions
  • Composite baseline of the latest baselines in the stream

LATEST element versions This is the default situation. Just do a make baseline of a component with a dependency definition.

Latest baselines This is a bit tricky. Select Edit dependencies. The OK button in the dialog window will be grayed out. Add a (any) component to the dependency tree of the component you want to baseline. Next, remove the component from the dependency tree. The OK button will be enabled. When you press it, UCM will prompt for a new baseline.

Note that it is impossible to make composite baseline composed of user-selected baselines.

For the second approach, we use the following procedure to create a composite baseline:
1. Create a rootless component in the PVOB. e.g. 

cleartool mkcomp -c "BNS_App_Common CBL" -nroot _BNS_App_Common_CBL@/vobs/Intral
 ink_pvob
2. Create the mainline project by adding all the components including the above rootless component. (clearprojexp &)
3. Edit Baseline Dependency to drag and drop all componennt baselines into the above rootless component, using middle mouse button in Unix server.
4. Remove all individual baselines from the "Recommended Baselines", left with only the composite baseline.
5. All child project will be created using the above composite baseline.

2.7. How to allow deliver/rebase, but block creating new activities?

Make a preop-trigger for mkact to disallow activity creation, except for the deliver and rebase activities. Check the CLEARCASE_POP_KIND variable. According to Tech Note 137366401 from Rational, the trigger could look like this in Perl: 

      # Get the integration stream name for this project
      my $istream = `cleartool lsproject -fmt "%[istream]p" $ENV{"CLEARCASE_PROJECT"}`;

      # Get the current stream and strip off VOB tag
      my $curstream = $ENV{"CLEARCASE_STREAM"};
      $curstream =~ s/\@.*//;

      # If it's the same as our stream, then it is the integration stream
      if ($istream eq $curstream) {
          # Only allow this mkact if it is a result of a deliver
          # Determine this by checking the parent op kind
          if ($ENV{"CLEARCASE_POP_KIND"} !~ /(deliver|rebase)_start/ ) {
              print "Activity creation is only permitted in integration ",
                    "streams for delivery or rebase.\n"; 
              exit 1;
          }

      }
      exit 0;

2.8. Can you use a component of a different PVOB in a project?

Yes you can, but only as read-only component. When selecting a component for a project, you have to specifiy the PVOB first, so just select a different PVOB.

2.9. Can you relocate or move a directory (or files) to another component?

When the components are allocated to different VOBs, it is not possible to relocate directories or files. UCM does not support cleartool relocate.

When the components are allocated to the same (multi-component) VOB, you could consider cleartool mv to move directories and files to a different component (within the same VOB), but unfortunately that does not work with UCM.

Instead, you can create the element(s) in the new component and remove it from the old component:

  1. Copy the (tree of) elements to the new component
  2. Add these (tree of) elements to source control
  3. Remove the (tree of) elements from the old location using cleartool rmname

In addition you need to change references to those elements (e.g. in make files) to use the path to the new location. As a temporary (transitory) fix you can make symbolic links using cleartool ln -s at the old location to "fool" existing references.

2.10. How to make view-private changes that are never delivered to the integration stream?

When checking out a file or directory, you need an activity and the new version is added to the change set of the activity. This has some adverse consequences:

  • Rebasing the stream will merge the changes into the development stream, instead of shifting the baseline. Not only does this create unnecessary versions in the development stream, it also makes it impossible to rebase to an older baseline.
  • Ultimately, you will have to deliver the (temporal) activity because newer versions created for different activities will have a dependency with the (temporal) activity

This is something you do not want for temporal changes. A workaround may be to deliberately create an eclipsed file. Make sure to do this in the same directory as where the file is you want to change temporary.

  1. Copy filename.c to filename.c.tmp
  2. Hide filename.c by adding the following line as first line to the config spec 

      element filename.c -none

  1. Rename (or copy) filename.c.tmp to filename.c
  2. Remove the read-only bit from filename.c to make it modifiable
  3. Restore the original config spec by the command 

      cleartool setcs -stream

The file is now view private and you can modify it freely without checking it out or specifying an activity. To revert back to the original file, just remove filename.c. Please be aware that a rebase operation may fail when having eclipsed files in you development view.

Warning: It is not a recommended practice to make eclipsed files.

2.11. How to use composite baselines?

Obvious answer seems to be to use the same way as recommending normal baselines. In other words, just put the composite baseline in the recommended baseline list. But when you do, some components may occur in the recommended baseline list more than once:

  • an component baseline occurs in more than one composite baseline, or even more than once in a single composite baseline
  • an component baseline occurs in a composite baseline and as individual component baseline

For the latter, the individual baseline has precedence over the composite baselines, indicated by (override) and (overridden) in the recommended baseline list. To overcome this situation you can make the selected baselines equal (by selecting the same baseline) or you can remove the individual baseline as it already occurs in the composite.

The former situation is more complex. Probably UCM will ask you to select a baseline explicitly to resolve version conflicts.

After resolving the baseline conflicts in the recommended baseline list (or accepting the override/overridden definitions), you can rebase the development streams to the recommended baseline.

Warning: When making a new composite baseline while one of the read-only components is overridden, will create a baseline for the read-only component. UCM considers this a modification of the component in the stream, although it is marked as read-only. As a result, you lose the freedom to rebase the read-only component to any (forward, backward of sideways) baseline. This is commonly known as a "parasite baseline".

2.12. How to enforce roles?

Although the promotion material suggests that UCM is designed for different roles (e.g. Project Manager, Developer and Tester), the current implementation of UCM does not support roles explicitly. Some operations are restricted to the owner (VOB owner, members of the ClearCase group, object owner, etc.) like in ClearCase.

To enforce explicit roles, use pre-op triggers to the UCM commands.


Add your solution and triggers here...

2.13. How strong is the link between ClearCase and ClearQuest?

The integration is quite loose actually. In fact it is only:

  • Activity names in ClearCase are identical to the ClearQuest record ID
  • Stream and project names in ClearQuest (these are field values) are identical to the stream and project names in ClearCase

So if there is a mismatch, simply change those values to the correct ones. And if the state of the activity in ClearQuest is wrong, then perform the state changes in ClearQuest to the correct it. These situations may occur for example after a restore of a (ClearCase or ClearQuest) database.

For missing activities:

  • If the ClearCase activity is missing, then make the activity 'current' in a stream and UCM will create it in ClearCase for that stream. Make sure to take the correct stream!
  • If the ClearQuest activity is missing, then synchronize ClearQuest with ClearCase (Project Explorer, Project properties, ClearQuest tab). In this case, the activity will get a new ID.

  • In ClearCase 2003 the Syncronize option has been removed from the Project Properties page in the Project Explorer. Instead you must use the new checkvob -ucm option. For example, if activity CQTST00001234 is missing in ClearQuest, you can repair it using this command: 
cleartool checkvob -ucm -fix activity:CQTST00001234@<pvob-tag>
    Scanning UCM related objects...
    This process may take a long time dependent on the number of UCM objects.
    Scanning object: activity:CQTST00001234@<pvob-tag> ...
    ccscan -- activity:CQTST00001234
    cleartool: Error: Cannot get ClearQuest activity record.
    Are you sure you want to fix it? [no] yes
    Fix: Created a ClearQuest record and repaired the links.
        "CQTST00001234" was renamed to "CQTST00001261".
    This activity was renamed to the ClearQuest ID.
-- BruceFiles? 08Dec2004

The communication with ClearQuest is performed by a process called CQINTSVR under Windows. This process requests the login username and password for ClearQuest only once and stores it in the Windows registry under the following keys: 

HKEY_CURRENT_USER\Software\Rational\Software\Common\CQIntSvr\<UserName>
HKEY_CURRENT_USER\Software\Rational\software\Common\CQIntSvr\UCM_SquidIntegration_<User Name>

If you want to change user names (e.g. because you accidentally entered the wrong one previously), delete these keysfrom the Windows registry and kill the CQINTSVR process. Next time ClearQuest is called from ClearCase, a login screen will pop up.

See also technote Technote 1123806


Add your answer here about how this is done under UNIX...

2.14. How to allow multiple users to recommend baselines in a stream?

UCM has the nasty habit to restrict recommending a baseline to the owner of the stream. Use the following policy settings to override this restriction: 

    M:\MY_PVOB>cleartool chproject -policy POLICY_CHPROJECT_UNRESTRICTED project:MY_PROJECT
"Updated policies on project:"MYPROJECT"
    M:\MY_PVOB>cleartool chproject -policy POLICY_CHSTREAM_UNRESTRICTED project:MY_PROJECT
"Updated policies on project:"MYPROJECT"
    M:\MY_PVOB>cleartool chproject -policy POLICY_CHSTREAM_UNRESTRICTED project:MY_PROJECT_integration
"Updated policies on project:"MYPROJECT_integration"

This will allow anyone to recommend baselines. If you to allow it to specific users only, you can attach a pre-op trigger to the chstream command.

Note that these policies are included in the GUI of the Project Explorer of UCM 2003.06.

2.15. Trying to deliver invisible files. Now what?

During the deliver you may encounter the following message: 

13 elements were skipped because they are not
 visible.  You should determine
 why they are not visible before you complete
 this deliver or rebase operation.  If
 these elements should be visible, cancel
 this operation, fix the problem, and
 re-run the operation.
An error occurred while checking out
 or merging the directories in the target view.
Unable to perform merge.
Unable to do integration.

In general, this situation occurs when you make changes to various files in a directory and then remove ('rmname') the directory. All of those files become invisible in the development view. So they are also invisible when you try to deliver them to the integration view. And because they are invisible, UCM can not check them out in the integration view to do the merge.

If this situation is deliberate because you actually do not need the elements anymore, then just go ahead and complete the delivery. But if you accidentally removed the directory (or some files), then you should first recover them in your development view before doing the deliver. So in that case, cancel the deliver, fix the problem and re-run the deliver.

2.16. Where can I find handy UCM triggers?

Try the ClearCase UCM Triggers page or the Rational ClearCase Add-ins page at the Rational DeveloperWorks site.

2.17. How to remove or avoid dependencies between activities?

Two of the most common causes for dependencies between activities are:

  • Directory changes. You can deal with this by:
    • Making directory changes only in one stream, e.g. the integration stream
    • Use a separate activity for directory changes that you can deliver independent of other changes

  • Rebase activities. You can deal with this by:
    • Rebasing only when you are finished with all activities that you are working on, and not make changes on those activities after you rebased (unless you are going to deliver them anyway).

To remove the dependencies, you have to move the dependent versions from one activity to another, or delete those versions (with rmver, NOT recommended!!). So either you deliver more versions (by moving versions from an activity that you do not want to deliver to an activity that you want to deliver) or you deliver less versions (by moving them out). Anyhow, keep in mind that by moving versions between activities you may lose track of what the changes belong together.

2.18. How to move data from one UCM component to another?

The simple answer is: you cannot.

The commands cleartool mv or cleartool relocate do not work across UCM components, regardless of the components being stored within a single VOB or in different VOBs.

Instead, use clearfsimport to "copy" the data from one UCM component to another and than use cleartool rmname to "remove" it from the old location. This way, the old history and version tree will not be available at the new location, and merging of data from the old location to the new location does not work (so you have to copy-paste it).

When moving data to another location within a UCM component, freely use cleartool mv. Version tree and history will be continue and filemerge works as usual.

2.19. How do I rename a stream?

The process for renaming a UCM stream is documented on IBM Rational's web site as Technote 21146827.

A summary of the steps required, for ClearCase 2002.05 and 2003.06, are as follows. Run all these commands from a view directory in the PVOB. You may need to mount the PVOB if you are working in Windows. Assume that you want to rename "dbaird_myproj" to "shared_myproj". 

    cleartool rename brtype:dbaird_myproj shared_myproj
    cleartool chstream -generate dbaird_myproj
    cleartool rename stream:dbaird_myproj shared_myproj
    cleartool setcs -stream -tag dbaird_myproj

The last step must be done for every view attached to the renamed stream.

If you are using ClearQuest enabled UCM, you will also need to use the checkvob command to update the stream name in all the ClearQuest activities linked to the renamed stream.

The ClearCase steps outlined above do not automatically update the stream name in the ClearQuest tickets that are linked to the renamed stream. These tickets will still contain the old stream name. The checkvob command must be used to fix the ClearQuest tickets.

  • The checkvob command must be run from a view context. Create a view on the renamed stream and cd into it.
  • Set the SQUID variables for the ClearQuest integration to make sure the checkvob command can login to ClearQuest successfully. 
      export SQUID_DBSET=2003.06.00
      export SQUID_USER=<username>
      export SQUID_PASSWORD=<password>
  • Run checkvob to preview the changes it will make. 
      cleartool checkvob -ucm -crm_only project:<project-name>@<pvob-tag>
  • If you are happy with the preview, re-run the command adding the -fix and -force options: 
      cleartool checkvob -ucm -fix -force -crm_only project:<project-name>@<pvob-tag> 

      Output will look like this:
      cqscan -- activity:CQSSI00010129
      cleartool: Error: ucm_stream field mismatch.
      Fix: Changed the ucm_stream field to "vps_helos_mrg".

2.20. How to do UCM from the commandline?

2.20.1 Create UCM objects on the commandline

2.20.1.1 Making a project VOB on the commandline 

    cleartool mkvob -ucm -nc -tag <vob name> -host <machine name> -hpath <host path> -gpath <global path> <vob>.vbw

For example: 

   cleartool mkvob -nc -ucm -tag /vobs/test_pvob -pub -host ccvob01 -hpath /export/vobstg01/test_pvob.vbs -gpath /mnt/rational/ccvob01/vobstg01/test_pvob.vbs /export/vobstg01/test_pvob.vbs

2.20.1.2 Making a component VOB on the commandline

To make a single component VOB 

   cleartool mkvob -nc -tag <vob name> -host <machine name> -hpath <host path> -gpath <global path> <vob>.vbw
   cleartool mkcomp -root <vob name> <component name>@<pvob name>

For example: 

   cleartool mkvob -nc -tag /vobs/test -pub -host ccvob01 -hpath /export/vobstg01/test.vbs -gpath /mnt/rational/ccvob01/vobstg01/test.vbs /export/vobstg01/test.vbs
   cleartool mkcomp -root /vobs/test component1@/vobs/test_pvob

To make a multi-component VOB 

   cleartool mkvob -nc -tag <vob name> -host <machine name> -hpath <host path> -gpath <global path> <vob>.vbw
   cleartool mkcomp -root <component dir> <component name>@<pvob name>

For example: 

   cleartool mkvob -nc -tag /vobs/test -pub -host ccvob01 -hpath /export/vobstg01/test.vbs -gpath /mnt/rational/ccvob01/vobstg01/test.vbs /export/vobstg01/test.vbs
   cleartool mkcomp -root /vobs/test/comp1 component1@/vobs/test_pvob
   cleartool mkcomp -root /vobs/test/comp2 component2@/vobs/test_pvob
   cleartool mkcomp -root /vobs/test/comp3 component3@/vobs/test_pvob

2.20.1.2 Making a component on the commandline 

      cleartool mkcomp -root <full directory name for component> <component name>@<pvob name>

For example: 

      cleartool mkcomp -root /vobs/src001/sdk ui_sdk@/vobs/pvob1

2.20.1.3 Making a project folder on the commandline

2.20.1.4 Making a project in a project folder on the commandline

2.20.1.5 Making an integration stream on the commandline

2.20.1.6 Making a development stream on the commandline

To make a development stream on an integration stream ...complete this description...

To make a development stream on a development stream ...complete this description...

2.20.1.7 Making an activity on the commandline

To make an activity on a stream of a project that is not ClearQuest enabled 

      cleartool mkact <activity name>

Please note, the actibity name can have no spaces. You can add an optional comment with the -c parameter.

To make an activity on a stream of a project that is ClearQuest enabled ...complete this description...

2.20.1.7 Making a baseline on the commandline

2.20.2 Change properties or policies of UCM objects on the commandline

2.20.2.1 Changing policies of a project on the commandline

2.20.2.2 Changing properties of a project on the commandline

2.20.2.3 Changing policies on a stream on the commandline

2.20.2.4 Changing properties of a stream on the commandline

2.20.3 List properties or policies of UCM objects on the commandline

2.20.4 Joining a project from the commandline

2.20.5 Delivering a stream from the commandline

There are two steps to this: the initial delivery and then completing the delivery. To deliver: 

      cleartool deliver
(This will deliver all activities) 

      cleartool deliver -act <activity name>
(if you want to only deliver a specific activity.)

Then you need to complete the delivery: 

      cleartool deliver -complete

2.20.6 Rebasing a stream from the commandline 

      cleartool rebase -rec
(Rebase to recomended baseline) 

      cleartool rebase -com
(Complete the rebase operation)

2.20.8 Recommending or promoting a baseline from the commandline

Recommending a baseline is done per stream. You recommend a baseline by changing the properties of the stream. 

      cleartool chstream -recommend baseline1,baseline2,...

You have to specify all baselines of the recommended baseline list, not only the changes compared to the current list of recommended baselines. This is also the way to add components to the recommended baseline list, which is a lot of work if you have to do that for many (read-only) components from the project explorer.

2.21. How do I rename a baseline?

NOTE: The Project Explorer will not used the renamed baseline identification, because it used an internal value of the baseline, called the baseline title which can not be renamed.

A baseline consists of 2 parts, a baseline name and a baseline label. Assume that you want to rename baseline "BL6_3_4_1" to "REL7_0". I use the Windows syntax, not the UNIX syntax. 

    cleartool rename baseline:BL6_3_4_1@\MyPVOB baseline:REL7_0@\MyPVOB
    cleartool rename lbtype:BL6_3_4_1@\MyPVOB lbtype:REL7_0@\MyPVOB

    cleartool rename baseline:BL6_3_4_1.1234@\MyPVOB baseline:REL7_0.1234@\MyPVOB
    cleartool rename lbtype:BL6_3_4_1.1234@\MyPVOB lbtype:REL7_0.1234@\MyPVOB
      :

Note that the suffixed number ( .1234 in this example) is added by UCM when using the same baseline name for different components in order to make the name unique.

2.22. How to look up the exact baseline name?

-- HeiniAarela? - 18 Dec 2004

Often you know the name you gave as the basename when you created a baseline, and want to know the exact name that ClearCase gave to a baseline of a particular component. Or you just want to know the list of all baselines with the same basename.

Especially when you are using a single root component in your project, you would like to know the exact name of the root baseline you created. This became a problem when upgrading to ClearCase 6.0, which uses a different algorithm in naming the baselines. In ClearCase 5.0, the root component always got the baseline name that didn't have the suffix number added, while its members all got a number added in the cleartool mkbl operation. Now, in ClearCase 6.0, it is the first member component that happens to get created that gets its baseline named without a suffix, and since the root component is always the last one, it can get a name without the suffix only if it happens to be the only component that had a baseline created that time.

2.22.1 How to find the exact names of the latest baselines?

If you are only interested in knowing the exact names of the very latest baselines in a stream, the solution is very simple (and fairly fast): 

  cleartool lsstream -fmt "%[latest_bls]p"

If the result is an empty list, you may want to instead list the foundation baselines (these have not been created in the same stream): 

  cleartool lsstream -fmt "%[found_bls]p"

2.22.2 How to find the exact names of the latest root baselines?

Sometimes you only want the baseline name of the root baseline, not its members. This you can do by listing the latest baselines as in the above, and then leaving out all member baselines from the list. To find out which of the listed baselines are members of each other, you need: 

  cleartool lsbl -fmt "%[depends_on_closure]p " BASELINELIST

Note that the cleartool lsstream command returns the baseline names without the " @\PVOB " suffix, and if the default directory is not in the PVOB, you have to add the suffix to the baseline names for cleartool lsbl. The cleartool lsbl command, on the other hand, returns its result with the suffix added when using the " %[depends_on_closure]p " format.

2.22.3 How to find the exact name of the latest baseline of a particular component?

This again can be done by first finding out all latest baselines and then picking up the particular component's baseline from the list.To find out which component each baseline belongs to, you need something like: 

   cleartool lsbl -fmt "%[component]p:%[name]p " BASELINELIST

2.22.4 How to find the exact names of baselines with a particular basename?

To find out the exact names of baselines that might not be the latest in a stream, you simply have to list all baselines created in the stream: 

  cleartool lsbl -short -stream STREAM

- and then make your pick by substring search, using the basename as the search string.

The lsbl command is very slow when no baselines are listed as argument. If you are interested only in one specific component, you can make it much faster by telling at least a component name: 

  cleartool lsbl -short -stream STREAM -component COMPONENT

The baselines are returned in the order they were created, and you have to select the last matching item from the list. This method is of course prone to errors when basenames are used in a way that makes the substring matching difficult.

2.23. How to list the contents of a baseline?

-- HeiniAarela? - 27 Dec 2004

UCM provides no direct method for listing the contents of a baseline.

Of course, the problem depends on your definition of "content" - it is possible to compare a baseline with the initial baseline of the same component(or, if the baseline descendes from an imported a label, you have to compare with the imported baseline): 

  cleartool diffbl -first -version BASELINENAME COMPONENTNAME_INITIAL

What you get is the full history of the baseline, including all intermediate versions of all involved elements, on all involved branches. Yes, not only the versions resulting in deliveries, but also all versions involved with the contributing activities from any involved sub-streams are listed!

Anyway, most of us think of the content of a baseline as the set of latest versions, excluding the intermediate versions. To reach that set of versions, there is only one way: ensure the baseline is fully labeled, and then find all versions with the label (which hopefully still has the same name as the baseline). This sounds fairly straight-forward, but if the baseline happens to be a composite, you have to look up element versions using the labels of its non-composite member baselines.

To ensure the baseline is fully labeled, you need: 

    cleartool chbl -full BASELINE

To get the non-composite members, you need: 

    cleartool lsbl -fmt "%[depends_on_closure]p " BASELINE

To look up the versions labeled with the baseline's label, you need: 

    cleartool find ROOTDIR -version "lbtype(BASELINE)" -print

- where ROOTDIR is the component root directory in the appropriate VOB. If you put all labels into the same query ( -version "lbtype(ONEBASELINE) || lbtype(OTHERBASELINE)"), use " -avobs " instead of the root directory.

2.24. How to report changes?

-- HeiniAarela? - 18 Dec 2004

The most basic question you can make is "What changes have been made since the latest baseline was created?" In order to answer this question, the Report Builder in ClearCase 6.0 provides the report "Activities Delivered But in No Baseline". This report is quite unusable in practice because it is so very slow. Just take a look at the script in C:\Program Files\Rational\ClearCase\reports\scripts\UCM_Streams\Activities_Delivered_But_in_No_Baseline.prl and you see how inefficiently the report has been implemented. First, they perform a full listing of all baselines created in the stream (" cleartool lsbl -long -stream $stream ") and a full listing of the stream content (" cleartool desc -l stream:$stream ") to make a comparison. This is already rather inefficient, but to complete the beauty, they perform the command " cleartool desc -fmt \"%[title]p\" \"activity:$act\@$pvob\" " separately for each activity that gets picked up for output!

Here you can find some hints for creating your own custom reports.

The cleartool diffbl command can be used to compare not only baselines but also the current content of a stream can be given as argument (in the form " stream:STREAMNAME ").

So to find out the latest changes, you have to

  1. Find out the latest (root component) baseline(s) as explained elsewhere in this ClearCase UCM FAQ.
  2. Use the diffbl command in the following form: 

      cleartool diffbl -first stream:STREAMNAME LATESTBASELINENAME

To format the report for your taste, you have to parse out the activity names from the output of this command, possibly add the " activity: " prefix and/or the " @\PVOB " suffix to the activity names, and then fetch the information by using =cleartool lsactivity= or cleartool describe.

For example: 

  cleartool desc -fmt "%Nd %u %[stream]p %n %[versions]Cp\n" ACTIVITYLIST

2.25. How to find out the appropriate PVOB name?

-- HeiniAarela? - 18 Dec 2004

Many of the commands you need in scripting are easier to use if the default directory is set to the PVOB. If it is not, you need to add the " @\PVOB " suffix to the UCM object names for most commands. So in all cases, you have to know the PVOB. But how to obtain it without asking it from user every time? Again, there is no direct solution.

You have to issue a command that returns some text that contains the PVOB tag. Preferably, it has to be a command that does not take too much time.

This one is fairly okay: 

  cleartool lsproject -fmt "Xn" -cview

- but you still have to parse out the PVOB name from the output. The cleartool lsstream would serve the same purpose. You do not need to give any argument as long as you are in a UCM view that belongs to a project which is defined in the PVOB you are interested in.

2.26. Why does conversion of a VOB directory to a component take so long?

You can use the Import VOB Directory as component function in the Project Explorer to convert a VOB directory to a component.

When you do, UCM will traverse all elements found under the directory, and for all directories found it will traverse through all versions of that directory and for each version of the directory it will traverse through all elements that are catelogued. Then again, if directories are found it will go through its subdirectories and versions to find more elements. Thus, many thousands of versions may be traversed which takes time, a lot of time...

Why does it do this? For all elements and versions it finds, UCM marks the element as "belonging to the component". Consequence is that when trying to convert another directory to a component, the traversion may run into an element that already belongs to an existing component. At that point, UCM refuses to make the component with an error message.

Please note that due to a bug in ClearCase 2003.06 (RATLC00728455), the traversion may run into an infinite loop. There is a hotfix, and maybe it has been solved in the meantime.

2.27. How to undo a deliver?

For a deliver a two things happen. First a unlabelled baseline is created that captures the activities that are delivered. Then an activity is created on the target stream to capture the merge results. And finally the baseline is merged into the target stream resulting in new element versions on the target stream captured in the deliver activity, and a deliver-arrow (hyperlink) is created for every merged element version.

To undo the deliver, you may do the following actions.

  • Remove the versions from the target stream to undo the merge. After this, the deliver result is done but you can not re-do the deliver yet. 

       cleartool rmver -xhlink ...

  • Remove the deliver baseline from the source stream. To do that, you first have to remove a hyperlink and then the baseline. Note that you will get warnings not to do this unless directed by Customer Support. So, be aware that you may mess up things badly! 

       cleartool describe -long deliverbl.MyStream.20050121.000000@\MyPvob
          :
       Hyperlinks:
         Integrate@1687@\MyPvob -> anyactivity:timeline040512.134120@\MyPvob
       cleartool rmhlink Integrate@1687@\MyPvob
       cleartool rmbl deliverbl.MyStream.20050121.000000@\MyPvob

WARNING: Do not undo delivers if you already have done additional delivers on top of the one you want to remove. This will mess up your configuration management badly. It is better to make additional corrections to your software and deliver those on top of the previous delivers.

2.28. Obscure error messages

2.28.1 Error: Unable to find a foundation arc entry in timeline


Add your answer here...

2.28.2 Error: Can't link an object into a directory with a different component root directory.

You will get this error when trying to do cleartool mv outside UCM (i.e. a non-UCM branch) on an element that belongs to a UCM component. If one version of an element belongs to a UCM component the entire element belongs to the UCM component. For a directory, all elements that are catalogued by any version of the directory belong to the UCM component.

You will also get this error when trying to cleartool mv an element across to another component.

2.29. Why are activities dependent?

Activity dependency can be caused by 2 reasons:

  • Overlapping change sets
  • Previous baselines

Overlapping change sets are the most common, and most obvious reason for activity dependency. It is based on the principle that successive versions always contain the changes of their predecessors. So if you want to deliver an activity A, UCM forced you to deliver activity B if (1) the change sets of A and B overlap, (2) activity B contains predecessor versions of activity A and (3) the change set of B contains versions that have not been delivered yet.

But even if the change sets of activity A and B do not overlap, UCM finds a dependency that is independent of the change sets. This "dependency" is not very obvious to the average user. All activities listed in a prior baseline on a stream must be delivered (or must have been delivered). In other words, activity A is always dependent on all activities in the previous baseline.

This is particularly important for development streams because UCM creates a (unlabelled) baseline for every deliver that is started. So when you deliver activity B to stream ProjX _PreIntegration, and then try to deliver activity A to stream ProjX _Integration, UCM will force you to deliver activity B to stream ProjX _Integration too because it is in the baseline, even when activities A and B do not overlap.

3. UCM information resources

3.1 Interesting books

3.2 Interesting articles

3.3 Interesting technotes


Please leave this list in numerical order


Edit • Attach • Print version • History: r56 < r55 < r54 < r53 < r52 • Backlinks • Raw View • Raw edit • More topic actions