test

Sun WorkShop TeamWare ユーザーズガイド

第 4 章 プロジェクトの開始

Sun WorkShop TeamWare を初めて使用するのは、既存のソフトウェア開発プロジェクトを TeamWare に移行する場合や、新しいソフトウェア開発プロジェクトを開始する場合が考えられます。

この章は、以下の節で構成されています。

既存の SCCS 管理プロジェクトの TeamWare への移行

既存の SCCS 管理されたプロジェクトを TeamWare へ移行するには:

  1. すべての SCCS 履歴ファイル (s.<ファイル名>) が SCCS という名前のディレクトリ内にあり、このディレクトリがソースファイルを含むディレクトリのすぐ下に存在していることを確認します。

    ワークスペース管理ツールは、SCCS によりバージョン管理されているファイルにのみ利用できます。

  2. プロジェクトのディレクトリ構造が編成済みの最新のものであることを確認します。

  3. ワークスペースとして最上位のディレクトリを指定して、「ファイル」⇒「ワークスペース作成」を選択します。

    指定した最上位ディレクトリの下に、Codemgr_wsdata ディレクトリが作成されます。

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

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

コンパイルの単位をディレクトリ単位で簡単にグループ化できるプロジェクト構造である場合は、デフォルトのワークスペース管理 FLP (ファイルリストプログラム) を使用できます。デフォルトの FLP についての詳細は、「FLP によるトランザクション対象ファイルのグループ化」を参照してください。

固有の方法で転送するファイルをグループ化しなければならないプロジェクトの場合は、独自の FLP を作成する必要があります。

SCCS 管理以外のプロジェクトの TeamWare への 移行

既存のプロジェクトを TeamWare へ移行するには:

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

  2. 作成したワークスペースのアイコンをダブルクリックして、「バージョン管理」ウィンドウを開きます。

  3. 「バージョン管理」ウィンドウで、「コマンド」⇒「新たにチェックイン」を選択します。

    「新たにチェックイン」ダイアログで、開発プロジェクトに含めるファイルを選択し、「初期コメント」区画に初期コメントを入力します。

RCS プロジェクトの TeamWare への変換

rcs2ws は、RCS ソース階層からワークスペースを作成するプログラムです。このプログラムは、RCS (Revision Control System) で開発されたプロジェクトを変換し、階層の上から下へ順番に RCS ファイル を SCCS に変換する作業を行います。

rcs2ws は、親ディレクトリの中の RCS ファイルを処理して SCCS ファイルに変換し、変換した SCCS ファイルをワークスペースに格納します。ワークスペースが存在しない場合は、rcs2ws によって作成されます。rcs2ws により親ディレクトリ階層が影響を受けることはありません。

rcs2ws は、ディレクトリを再帰的に検索します。

rcs2ws は、ファイルを変換するために RCS の co コマンドと SCCS の admin、get、delta コマンドを呼び出します。これらのコマンドは、ユーザーの PATH 変数を使って検索されます。SCCS コマンドが検出できない場合は、/usr/ccs/bin ディレクトリが検索されます。

rcs2ws では、RCS キーワードを SCCS キーワードに変換しません。キーワードは SCCS デルタ内のテキストとして処理されます。

rcs2ws の使用

rcs2ws を使用するには:

  1. コマンドプロンプトで、rcs2ws -p <親ディレクトリ> -n <ファイルまたはディレクトリ> と入力します。

    -p オプションを必ず使用して RCS ソース階層の名前を指定します。

    -n オプションを使用すると、実際の処理を行わずに結果を参照することができます。

    相対ファイル名は、親ディレクトリと対応付けて解釈されます。

    CODEMGR_WS 環境変数には、ユーザーのデフォルトのワークスペース名が格納されます。-w オプションを使用しなかった場合は、このワークスペースが自動的に使用されます。子ワークスペースを指定するには、-w オプションを使用します。rcs2ws(1) マニュアルページを参照してください。

    指定したディレクトリがすでにワークスペース内にある場合、そのワークスペースは子ワークスペースとなります。ワークスペース内になければ、rcs2ws がワークスペースを作成します。

    注 -

    親ディレクトリ下のすべての RCS ファイルを変換する場合は、"." ディレクトリを使用します。

設定が完了したら、次の手順に進みます。

  1. -p オプションだけを使用して rcs2ws コマンドを実行します。

    通常、SCCS get (g-ファイル) は、ファイルが RCS から変換された後で抽出されます。処理を停止させたい場合は、-g オプションを使って変換を行います。(rcs2ws -g)

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 組の変更内容が統合ワークスペースに反映されます。以下同様に作業が進められ、最後にプットバックトランザクションを実行する開発者は、それ以前にこのグループ内で行われたすべての変更が反映されるように統合ワークスペースを更新しなければなりません。

複層階層の利点

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

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

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

複層階層の欠点

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

製品リリースに関する考慮事項

プロジェクトの階層構造を計画するときは、製品のリリースをどのように計画するかということを考慮します。ワークスペース階層の構造はいくつかの角度から検討して決定しますが、その目的の 1 つはメジャー、マイナー、パッチの各リリースをスムーズに準備できるようにすることにあります。ここでは、ユーザーが考慮すべき点についていくつか説明します。たとえば、開発する製品がこの階層モデルに適しているかどうか、または製品を別の方法で構築すべきかどうかなどについてです。

ワークスペースは、製品リリースを準備する集結場所としてリリースごとに専用のものを用意することをお勧めします。リリース用ワークスペースは、最上位の「製品」ワークスペースの下に置きます。また、製品ワークスペースは、通常の開発作業が統合されるワークスペースより上の階層に置く必要があります。このように製品ワークスペースを上の階層に設定すると、現在のリリースを破壊することなく次のリリースの開発を開始できます。

製品ワークスペースにファイルを転送した後、ブリングオーバートランザクションを使用して、そのファイルをリリースワークスペースにコピー (ブリングオーバー) します。リリースワークスペースは、マスターファイルの作成場所として使用したり、必要に応じて以降のリリースのために作業内容を保存しておく領域として使用できます。

図 4-3 は、1 つの製品ワークスペースと 6 つのリリース用のリリースワークスペースから構成される階層を表わしています。

図 4-3 製品およびリリースワークスペースのある階層

Graphic

注 -

親子関係の変更機能を使用すると、リリースワークスペース間でファイルを直接コピーすることができます。詳細は、「親子関係の変更例」を参照してください。

ソースファイルへのアクセスの調整

ソースファイルの変更が複数の開発者によって行われる場合は、ソースファイルへの書き込みアクセスを調整することが重要になります。ファイル更新記録を保存することにより、変更が行われた時期と変更の目的を残しておくことができます。

ソースコード管理システム (SCCS) を使用すると、ソースファイルへの書き込みアクセスを管理し、ファイルの変更を監視できます。SCCS では、ファイルを更新できるのは、一度に 1 人のユーザーに限られ、すべての変更が履歴ファイルに記録されます。

バージョン管理ツールは SCCS 用の GUI で、SCCS コマンドを意識することなくファイルの操作や基本的な SCCS 機能を実行できます。ファイルのチェックインやチェックアウト、履歴分岐の表示、特定の分岐への移動などを簡単に行うことができます。

バージョン管理ツールを使用して、以下の作業を行うことができます。

バージョン管理ツールを使用すると、上記の作業を簡単に行うことができ、並行開発プロジェクトの効率が向上します。

分岐

SCCS ファイルに適用されるデルタは、ファイルの初期バージョンをルートとしたツリーのノードとして考えることができます。ルートデルタには、デフォルトで 1.1 の番号が付けられます。SCCS デルタ ID (SID) は、リリース番号とレベル番号の 2 つの部分から構成されます。ルートデルタ以降のデルタ (ノード) は、1.2、1.3 というように順番に番号が付けられます。この構造は、SCCS デルタツリーのトランク (幹) と呼ばれ、SCCS ファイルが通常の順編成ファイルとして開発されることを表わしています。

ツリーには、別の分岐を作成しなければならない場合もあります。分岐は、バグの修正のように、並行して開発される複数のバージョンを追跡するために使用することができます。

分岐デルタの SID は、リリース番号、レベル番号、分岐番号、シーケンス番号の 4 つの部分から構成され、<リリース番号>.<レベル番号>.<分岐番号>.<シーケンス番号>という形になります。分岐番号は、特定のトランクデルタの子孫である分岐ごとに割り当てられ、最初の分岐は 1、次の分岐は 2 というように順番に番号が付けられます。シーケンス番号は、特定の分岐上の各デルタに順番に割り当てられます。したがって、1.3.1.1 は、1.3 のデルタから派生した最初の分岐の最初のデルタとして識別されます。このデルタの 2 番目の分岐には、1.3.2.1 という番号が付けられます。

分岐の概念は、ツリー内のどのデルタにも適用できます。分岐番号は、トランクに対する相対位置とは無関係に、分岐が作成された順番に割り当てられます。したがって、分岐デルタは、常にその名前で識別することができます。分岐のデルタ名からトランクデルタを識別することはできますが、トランクデルタから分岐デルタまでの完全なパスを判断することはできません。

たとえば、デルタ 1.3 に分岐が 1 つ存在する場合、その分岐上のデルタはすべて 1.3.n という名前になります。この分岐上のデルタから、新たに別の分岐が派生している場合、その新しい分岐上のデルタの名前は、1.3.2.n になります。1.3.2.2 というデルタ名からわかることは、トランクのデルタ 1.3 を祖先とする 2 番目に作成された分岐上で 2 番目に作成されたデルタである、ということです。ただし、1.3.2.2 というデルタ名から、そのデルタとトランクの祖先 (1.3) との間に存在しているすべてのデルタを知ることはできません。