test

Sun WorkShop TeamWare ユーザーズガイド

TeamWare による新しいソフトウェア開発プロジェクトの開始

TeamWare を使って新しいプロジェクトを開始するには:

  1. 「ファイル」⇒「ワークスペース作成」を選択して、プロジェクトの最上位ディレクトリ (および、その下の Codemgr_wsdata ディレクトリ) を作成します。

  2. 通常と同じ方法で SCCS ベースの開発階層を設定します。

    このとき、すべての SCCS 履歴ファイル (s. <ファイル名>) が、ソースファイルを格納するディレクトリのすぐ下にある SCCS という名前のディレクトリに格納されるようにします。

  3. 作成ブリングオーバートランザクションを使用し、ワークスペース階層を作成します(「既存のファイル階層からのワークスペースの作成」を参照)。

    ワークスペース階層に関する説明は、「ワークスペース階層の準備」を参照してください。

    注 -

    デフォルトの FLP は、ディレクトリごとにファイルを再帰的にグループ化します。デフォルトの FLP を使用する場合は、このことを考慮してコンパイル単位にファイルを配置してください。新しいプロジェクトで、転送時にほかの方法でファイルをグループ化する必要がある場合は、独自に作成する FLP に適合する方法でプロジェクト階層を設定する必要があります。

ワークスペース階層の準備

プロジェクトのワークスペースをどのように構成するかは、ワークスペース間のファイル転送や製品リリースの準備方法に影響します。この節では、プロジェクトに最適なワークスペース階層を選択するために必要な事柄について説明します。ワークスペース階層に関してユーザーがすでに決定している内容も、ワークスペース管理ツールからワークスペースの親子関係の変更機能を使って変更できます。詳細は、「ワークスペースの親子関係の変更」を参照してください。

ワークスペース階層は、2 層以上に階層化される親と子のワークスペースを指しています。階層内の層の数は、この階層を構成するワークスペースの数とは関係ありません。親ワークスペースとその子ワークスペースからは 2 層が構成されます。また、親ワークスペースが 3 つの子ワークスペースを持つ場合でも、層の数は 2 つです。親ワークスペース、その子、および孫が存在する場合は、3 つの層が構成されます。図 4-1 は、単層階層 (3 層) を示し、図 4-2 は、複層階層 (4 層) を示しています。

図 4-1 単層階層 (3 層)

Graphic

図 4-2 複層階層 (4 層)

Graphic

ファイル転送に関する考慮事項

ワークスペース階層の設定方法によって、階層内でのファイル転送の方法が変わることがあります。

ファイルシステムへのアクセス

ワークスペース間でファイルを転送 (ブリングオーバーまたはプットバック) するためには、親と子の両方が同じファイルシステムにマウントされている必要があります。ファイルシステムの接続には、オートマウンタを使用することができます。

単層階層と複層階層

適切なワークスペースを設計するためには、単層階層と複層階層の利点と欠点を理解している必要があります。

単層階層の利点

単層ワークスペース階層では、多数の開発者が 1 つの統合ワークスペースにファイルをプットバックします。単層階層の利点は、開発者がお互いのファイルに直接アクセスできる点にあります。開発者 A が統合ワークスペースに自分のファイルをプットバックした時点で、開発者 B は、更新ブリングオーバートランザクションを使用して、開発者 A が変更した内容にすぐにアクセスすることができます。

単層階層の欠点

単層階層では、統合ワークスペースの内容が頻繁に変更されるため、各開発者は自分のソースを最新の状態に保つためにブリングオーバートランザクション、構築、テストを頻繁に行う必要があり、時間が無駄になるという欠点があります。最初の開発者がプットバックを実行すると、その変更内容だけが統合ワークスペースで更新されます。次に 2 番目の開発者がプットバックを実行すると、この開発者と前回の変更の 2 組の変更内容が統合ワークスペースに反映されます。以下同様に作業が進められ、最後にプットバックトランザクションを実行する開発者は、それ以前にこのグループ内で行われたすべての変更が反映されるように統合ワークスペースを更新しなければなりません。

複層階層の利点

統合ワークスペースと開発ワークスペースの間に副統合ワークスペースの層を置くことによって、開発者が自分の変更内容を統合ワークスペースへプットバックするために必要な時間を、大幅に削減することができます。

ある開発者が統合ワークスペースに変更ファイルをプットバックした場合、ほかの開発者は、その変更内容を自分のワークスペースにブリングオーバーし、モジュールを再構築し、自分が加えた新しい変更内容をテストしてからでないと、プットバックトランザクションを実行できません。このように、プットバックが頻繁に行われると、それだけ衝突の発生する可能性は大きくなります。

プロジェクトに多数の開発者が関わっている場合は、ブリングオーバー、再構築、テストという作業は、煩雑で時間のかかるものになります。そこで、関連するコードを分担する少人数の開発者グループが、副統合ワークスペースで作業を行うようにすれば、そのワークスペースは比較的安定した状態になり、構築とテストに費やす手間や時間を軽減することができます。もちろん、副統合ワークスペース自体の内容を共通の統合領域にプットバックする際には、ほかの開発用ワークスペースでの変更内容をすべて統合しなければなりません。ただしほとんどの場合、統合作業の単位を大きくして回数を減らした方が、全体の作業は効率化されます。

複層階層の欠点

副統合ワークスペースをいくつか使用する複層階層には、次の欠点があります。