ベースラインの作成またはプレビュー

ベースラインを作成し、作成をプレビューできます。ビルド・マネージャーまたは ccm_admin ロールのユーザーは、1 つ以上のプロジェクト、ベースライン、またはプロジェクト・グルーピングから、ベースラインを作成できます。

このタスクについて

ccm baseline -c|-create [(-p|-project project_spec)...]
             [(-bl|-baseline baseline_spec)...]
             [(-pg|-project_grouping project_grouping_spec)...]
             [-rehearse] [-r|-release release_spec] [-purpose purpose]
             [-d|-desc|-description description] 
             [-vt|-version_template version_template] [-b|-build build]
             [-s|-state state] ([-subprojects] | [-all_subprojects] |
             [-no_subprojects]) 
             ([-cpu|-check_project_update] | [-nocpu|-nocheck_project_update])
             [baseline_name]
-all_subprojects
追加するプロジェクトのメンバーであるすべてのサブプロジェクトを含むように指定します。このオプションは、-project-project_grouping、および
-baseline オプションを使用して追加されたプロジェクトに適用されます。
-b|-baseline baseline_spec
このオプションを -create と一緒に使用して、ベースライン仕様を指定した場合、指定された既存のベースラインのプロジェクトが新しいベースラインに追加されます。

–subprojects-no_subprojects–all_subprojects を使用すると、どのサブプロジェクトが追加されるかに影響します。

デフォルトでは、–baseline を使用し、–project を使用しない場合、サブプロジェクトは含まれません。しかし、–project–baseline の両方を使用した場合、–project が暗黙的に指示する –subprojects のデフォルト値が、–baseline が暗黙的に指示する –no_subprojects のデフォルト値よりも優先されます。

baseline_name
ベースラインに割り当てられる名前を指定します。ベースラインを作成する際に、正式なベースライン名を割り当てることができます。

baseline_name を指定しない場合、固有の名前がベースラインに自動的に割り当てられます。このデフォルト名の形式は、yyyymmdd です。必要に応じて、デフォルト名の後に下線と増分番号を付けて固有の名前にします。例えば、2002 年 4 月 1 日に作成された 1 番目のベースラインのデフォルト名は 20020401 です。同じ日に作成された 2 番目のベースラインのデフォルト名は、20020401_1 になります。

-b|-build build
新しいベースラインのビルド番号または ID を指定します。 ビルド番号または ID は、任意の単一行のテキスト値です。通常、build 値には、何らかの形のビルド番号が含まれます。
-cpu|-check_project_update
ベースラインを作成する前にいずれかのプロジェクトの更新が必要かどうかをチェックするように指定します。このチェックによって、プロジェクト・グルーピングのベースラインとタスクが最後に再表示されてから更新されていないプロジェクトが表示されます。
デフォルトは、ccm.cli.baseline.create.checkprojectupdate 設定によって決まります。
-d|-desc|-description description
新しいベースラインに使用する説明を指定します。説明は、単一行のテキストで、改行文字を含むことはできません。
-nocpu|-nocheck_project_update
ベースラインを作成する前にいずれかのプロジェクトの更新が必要かどうかをチェックしないように指定します。
デフォルトは、ccm.cli.baseline.create.checkprojectupdate 設定によって決まります。
-no_subprojects
プロジェクトの追加時に、サブプロジェクトを追加しないように指定します。 このオプションは、-project-project_grouping および -baseline を使用して追加されるプロジェクトに影響を与えます。サブプロジェクトは、プロジェクトとして明示的に指定された場合、または指定されたプロジェクト・グルーピング、あるいはベースラインのメンバーである場合に含められます。

-project_grouping または -baseline が指定されていない場合、デフォルトは
-subprojects です。 -project_grouping または -baseline を指定した場合、デフォルトは -no_sub_projects です。

-p|-project project_spec
1 つ以上のプロジェクトを新しいベースラインに追加するように指定します。デフォルトでは、プロジェクトの追加時に、その階層全体も追加されます。このデフォルト設定は、-no_subprojects オプションを使用することで、指定変更できます。
-pg|-project_grouping project_grouping_spec
指定されたプロジェクト・グルーピング内のプロジェクトを新しいベースラインに追加するように指定します。デフォルトでは、プロジェクト・グルーピングの追加時に、そのプロジェクト・グルーピング内のプロジェクトのみが追加されます。プロジェクト・グルーピングの一部でないサブプロジェクトは、追加されません。この動作を指定変更するには、–all_subprojects オプションを使用します。

–subprojects-no_subprojects、および –all_subprojects オプションは、どのサブプロジェクトがプロジェクト・グルーピングと共に追加されるかに影響します。

-purpose purpose
新しいベースラインに使用する目的を指定します。指定されていない場合、デフォルトの目的は次の優先順位に従って設定されます。
  • ベースラインが指定されている場合、最初に指定されたベースラインの目的を使用する。
  • ベースラインが指定されず、プロジェクト・グルーピングが指定されている場合、最初に指定されたプロジェクト・グルーピングの目的を使用する。
  • ベースラインとプロジェクト・グルーピングのいずれも指定されていない場合、最初に指定されたプロジェクトの目的を使用する。

purpose は、プロジェクトの用途を指定する設定です (例えば、Insulated DevelopmentIntegration TestingSystem Testing など)。

-purpose を指定した場合は、-release も指定する必要があります。

-rehearse
作成するベースラインおよびベースラインの名前を構成するプロジェクトとプロダクトをリストします。ベースラインは作成しません。

バージョン・コンフリクトが発生した場合、競合しているすべてのプロダクトとプロジェクトが警告に示されます。作成されたバージョンが新しいベースラインに存在する場合、または正当なバージョン・ストリングでない場合に、コンフリクトが発生します。

-release release_spec
新しいベースラインに使用するリリースを指定します。ベースラインを作成するときに、アクティブ・リリースを 1 つ指定できます。指定されていない場合、デフォルトのリリースは次の優先順位に従って設定されます。
  • ベースラインが指定されている場合、最初に指定したベースラインのリリースを使用する。
  • ベースラインが指定されず、プロジェクト・グルーピングが指定されている場合、最初に指定されたプロジェクト・グルーピングのリリースを使用する。
  • ベースラインとプロジェクト・グルーピングのいずれも指定されていない場合、Synergy は、最初に指定されたプロジェクトのリリースを使用する。

-release を指定した場合は、-purpose も指定する必要があります。

-state state
ベースライン作成時のベースラインの状態を指定します。ベースライン作成時の有効な状態は、test_baselinepublished_baselineおよび released のいずれかです。ベースラインのデフォルトの状態は test_baseline です。 開発者は、この状態のベースラインを表示でき、手動で使用できます。しかし、最新のベースラインとして自動的に取得することはありません。 SQE は、これをテストに使用できます。テストに合格したら、ビルド・マネージャーは、テスト・ベースラインを published_baseline に移行させて、開発者が使用できるようにする必要があります。

released 状態でベースラインを作成することは、published_baseline 状態でベースラインを作成してからリリースすることと同じです。

-subprojects
追加するプロジェクトのコンポーネント名とリリースが一致するサブプロジェクトを含めるように指定します。コンポーネント名は正確に一致しなければなりません。コンポーネント名を持たないリリースは、コンポーネント名を持たない別のリリースとのみ一致します。

このオプションは、-project-project_grouping、および
-baseline オプションを使用して追加されたプロジェクトに適用されます。これは、-project_grouping または
-baseline が指定されていない場合の、デフォルトの動作になります。-project_grouping または -baseline が指定されている場合、デフォルトは -no_subprojects です。

-vt|-version_template version_template
新しいベースライン内のプロジェクトまたはプロダクトに使用するバージョン・テンプレートを指定します。コマンド中に作成された新しいプロジェクトとプロダクトのバージョンは、バージョンに version_template を使用します。

version_template は、%keyword または %{keyword} という形式のオプションのキーワードを含む任意のストリングです。このキーワードには、任意の Rational Synergy 属性または組み込みキーワードを使用できます。

属性を展開するとき、検査対象のビルド管理プロジェクトまたはプロダクトの対応する属性値が使用されます。指定されたキーワード名に属性または組み込みキーワードが見つからない場合、キーワードは空のストリングに置き換わります。

ベースライン内の任意のプロジェクトまたはプロダクトの、インスタンス化された version_template に、バージョン・ストリングで使用が認められていない文字が含まれている場合、それらの文字はデフォルトのバージョン・ストリング置換文字に置き換えられます。この設定は、baseline_template_repl_char オプションを使用してサーバーの ccm.ini ファイルで指定されます。この文字のデフォルトは下線 (_) です。例えば、%platform がバージョン・テンプレートに含まれており、ビルド管理プロジェクトのプラットフォームが SPARC-solaris である場合、バージョン・ストリングにはストリング SPARC_solaris が含まれます。あるいは、%release がプロダクトのバージョン・テンプレートに含まれており、prep プロダクトのリリースが CM/6.5 である場合、バージョン・ストリングにはストリング CM_6.5 が含まれます。

ベースライン内の任意のプロジェクトまたはプロダクトの、インスタンス化された version_template が、そのプロジェクトまたはプロダクトの別のバージョンで既に使用されている場合、下線 (_) と、バージョンを固有にする最初の整数 (1 から始まる) を付加することによって、バージョンは固有になります。これによってバージョン・ストリングが長くなりすぎる場合は、現在の日付に基づくバージョンが、そのプロジェクトまたはプロダクトに使用され、警告が表示されます。

–version_template を指定しない場合、デフォルト・テンプレートが使用されます。詳しくは、『baseline コマンド』の「バージョン・テンプレート仕様」を参照してください。

プロジェクトのワークエリア・テンプレートにそのバージョンが含まれている場合、ワークエリアは更新されます。ワークエリアが可視ではないためにワークエリアを更新できず、-skip_nonvisible_projects が使用されていない場合、操作は続行されて、すべてのエラーが報告されます。ワークエリアが可視であるが、他の理由 (適切なファイルのアクセス権限が欠如、またはディスク領域の不足など) で更新できない場合、操作は続行されますが、すべての障害が報告されます。


フィードバック