Home/ Questions/Q 8461477
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T13:53:28+00:00

Is it possible to access environment variables in the config spec in clearcase. I

  • 0

Is it possible to access environment variables in the config spec in clearcase.

I have this code:

element /folder/... /main/current_branch/LATEST

I wish to set my development up so as that I can update the branch by simply setting some envvars. I would like somthing like this to work is it possible?

element /folder/... /main/$current_branch/LATEST

where $current_branch should return the current branch set in that environment variable.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    AFAIK, that is not possible.

    The way I handle that is by having templates that I fill in (automatically). But I also use separate views; views are disposable and I rebuild my views routinely (every week, every couple of weeks, sometimes a few times in a day if I need to be sure of the cleanliness of the builds).

    I’d show you my scripts but there are a large number of them, and they’re fairly intricately intertwined with each other and with the working environment we have (multiple but overlapping VOBs for each of a number of major versions of a number of products, with some parts of the config spec provided by CM and custom preambles to identify what I’m working working on). We’ve been using ClearCase for about 18 years now.

    The net result is a config spec for a bug fix branch that looks like:

    # @(#)$Id:243260.jleffler.toru.cs,v 1.1 2011/08/30 15:23:02 jleffler Exp $
#
# Config Spec for Bug 243260 - Blah, blah, blah, blah

element * CHECKEDOUT
element * .../TEMP.243260.jleffler/LATEST
mkbranch -override TEMP.243260.jleffler

#time 26-Jul-2009.00:00:00UTC-08:00

element /vobs/main_vob/...  /main/LATEST
element /vobs/other_vob/...        dist.1.00 -nocheckout

include /atria/cspecs/product/1.23/product-1.23.4
#include /atria/cspecs/product/1.16/product-1.16.8

element * /main/LATEST

    The bit between the commented out time stamp and the catch-all rule is provided by CM. The bit above the time stamp is custom to the branch (TEMP.243260.jleffler — which identifies it as a temporary branch, the bug fix which it is for, and who is doing the work). The template actually lists about 10 different config specs from CM, and I just delete the ones that aren’t relevant. The view name is based on the bug number, my login, and the machine where it’s created (toru). I’ve disguised most of the rest, but it is based on a bug cspec that I created earlier today. My bug.view script took the bug number, a description, the path for the view working storage, and the VOBs where I needed the branch created and went off and set everything up automatically. (And I’m still archaic enough to use RCS to keep my cspecs under control.)

    Some of my views last a long time (by name). For example, the current release reference view will survive for the 5+ years that the release will be supported. It’ll be rebuilt hundreds of times over that period, but the name remains the same: prod-1.23-ref.jleffler.toru. So the cspec for that will change over time, as different work is needed, but the basic cspec is three lines — CHECKEDOUT, include standard CM provided configuration file, and LATEST.

    • 0