いいえ、環境変数に基づく構成仕様は見たことがありません。config_spec man pageを
見て、構成仕様と「構成仕様の仕組み」を書いています。その可能性について言及しているものはありません。
動的ビューの場合、環境変数に基づいて構成仕様を動的に変更するスクリプトを見ましたcleartool setcs(動的ビューでは更新がほぼ瞬時に行われるため)。
current_branch注: が常に から直接派生するとは限らないことを忘れないでください/main。私は次の構文を使用することを好みます。
element /folder/... .../my_branch/LATEST
my_branch直接の「親」ブランチに依存せずに を選択するため(ただし、ベース ClearCaseには実際の「親」ブランチはありません)。
私の知る限り、それは不可能です。
私がそれを処理する方法は、(自動的に) 入力するテンプレートを用意することです。ただし、別のビューも使用します。ビューは使い捨てであり、定期的にビューを再構築します (毎週、数週間ごと、ビルドのクリーン度を確認する必要がある場合は 1 日に数回)。
私のスクリプトをお見せしたいと思いますが、それらは多数あり、それらは相互に、また私たちが使用している作業環境とかなり複雑に絡み合っています (多数の主要バージョンの多数のメジャー バージョンのそれぞれに、複数の重複する VOB があります)。 CM によって提供される構成仕様の一部と、私が取り組んでいるものを特定するためのカスタム プリアンブル)。ClearCase を約 18 年間使用しています。
最終的な結果は、次のようなバグ修正ブランチの構成仕様です。
# @(#)$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) に基づいています。私は残りのほとんどを偽装しましたが、それは私が今日作成したバグ cspec に基づいています。じぶんのbug.viewスクリプトは、バグ番号、説明、ビューの作業用ストレージへのパス、ブランチの作成が必要な VOB を受け取り、すべてを自動的にセットアップしました。(そして、私はまだ RCS を使用して cspec を管理するのに十分古いです。)
私の見解のいくつかは（名前で）長く続きます。たとえば、現在のリリース参照ビューは、リリースがサポートされる 5 年以上存続します。その期間に何百回も再構築されますが、名前は同じままです: prod-1.23-ref.jleffler.toru. そのため、別の作業が必要になるため、その cspec は時間の経過とともに変化しますが、基本的な cspec は 3 行 (CHECKEDOUT、標準の CM 提供の構成ファイルを含める、および LATEST) です。