在“清除案例"配置规范中访问环境变量 [英] Accessing environment variables in Clear Case configuration specification

问题描述

是否可以用大写字母访问配置规范中的环境变量.

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

我有此代码:

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

我希望进行开发，以便可以通过简单地设置一些envvars来更新分支.我想像这样的东西行得通吗?

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

其中$ current_branch应该返回该环境变量中设置的当前分支.

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

推荐答案

AFAIK，

我处理该问题的方法是拥有(自动)填写的模板.但是我也使用不同的观点.视图是一次性的，我会定期重建视图(如果需要确保构建的整洁，每周，每两周，有时一天几次).

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).

我将向您展示我的脚本，但是其中有很多脚本，它们彼此之间以及与我们所拥有的工作环境都错综复杂地交织在一起(许多主要版本的VOB都有多个但重叠的VOB许多产品，其中一些配置规范是由CM提供的，还提供了一些自定义的前导码来标识我正在从事的工作).我们已经使用ClearCase大约18年了.

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

注释掉的时间戳和包罗万象的规则之间的位由CM提供.时间戳上方的位是分支的自定义名称(TEMP.243260.jleffler-将其标识为临时分支，它用于的错误修复以及由谁来进行工作).该模板实际上列出了CM的大约10种不同的配置规范，而我只是删除了那些不相关的规范.视图名称基于错误号，我的登录名以及创建该视图的机器( toru ).我掩盖了其余大部分内容，但这是基于我今天早些时候创建的bug cspec.我的 bug.view 脚本记录了错误号，描述，视图工作存储的路径以及需要创建分支并自动关闭并设置所有内容的VOB.(而且我仍然很老套，无法使用RCS来控制我的cspec.)

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.)

我的某些观点持续了很长时间(按名称).例如，当前版本参考视图将在该版本受支持的5年以上时间内有效.在此期间它将被重建数百次，但名称保持不变: prod-1.23-ref.jleffler.toru .因此，cspec会随着时间的推移而变化，因为需要进行不同的工作，但是基本的cspec是三行-CHECKEDOUT，包括标准CM提供的配置文件和LATEST.

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.

这篇关于在“清除案例"配置规范中访问环境变量的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！