Sun WorkShop TeamWare ユーザーズガイド

ワークスペース管理ツールによる開発事例

ワークスペース管理ツールは、そのデフォルトの設定を変更することによって、プロジェクトに適したツールに変更できます。こうしたカスタマイズ方法については、第 6 章「ワークスペースの操作と設定」で詳しく説明します。ワークスペース管理されているプロジェクトのすべてのソースファイルは、UNIX のソースコード管理システム (SCCS) で管理されます。ワークスペース管理ツールは、単に SCCS 管理されているファイルをコピーするだけです。開発者は自分のワークスペース内で通常の方法によって SCCS を使用します。たとえば、SCCS コマンドを使用して次のことを行います。

ファイルの作成
デルタの作成
ファイルの編集
コメントの追加
ファイルのチェックイン

SCCS 履歴ファイルは SCCS のサブディレクトリに置かれます。これは、ワークスペース管理ツールを利用していないプロジェクトで SCCS を使用する場合とまったく同様です。ワークスペース間でファイルをコピーし、変更のあったファイル同士をマージすると、ワークスペース管理ツールは SCCS 履歴ファイルを操作し、すべてのコメントとデルタを保存します。

ワークスペース

ワークスペースはワークスペース管理システムの基本となる作業領域です。ワークスペースによってプロジェクトの各開発者はほかの開発者と分離され、それぞれの作業を並行して進めることが可能になります。プロジェクトファイルは、ワークスペース管理ツールのコマンドを使用してワークスペース間でやりとりすることができます。ワークスペースは、ディレクトリとそのサブディレクトリの階層です。ワークスペースを作成すると、ワークスペース管理ツールはそのワークスペースの下に Codemgr_wsdata という特別なサブディレクトリを作成します。Codemgr_wsdata ディレクトリには、ワークスペースに関する情報が含まれています。

ワークスペース管理ツールを利用したプロジェクトは、最初に最上位のワークスペースに作成され、関連するすべてのサブディレクトリがその下に作成されます。この最上位のワークスペースから別のワークスペースが作成されると、元のファイルシステム階層が作成しなおされ、新しいワークスペースが形成されます。次に挙げる例では、最上位ディレクトリ boatspex の下にあるワークスペースで開発者が作業を開始しています。このワークスペースは /usr/src/ws ディレクトリの下にあります。

図 2-1 プロジェクトのファイルシステム階層

Boatspex プロジェクトの一員として作業する開発者は、オリジナルのワークスペースのコピーを任意のファイルシステムに作成します。新しいワークスペースにコピーされたファイルシステムのワークスペースの内容は、オリジナルのワークスペースのものと同一になります。たとえば、自分のホームディレクトリに新しいワークスペースを作成すると、図 2-2 に示すようなファイルシステム階層が得られます。

注 -

プロジェクトの一部のみを担当する場合は、その担当部分だけをコピーすることもできます。

図 2-2 新しいワークスペース

なお、ワークスペースディレクトリ (boatspex) の上のディレクトリは、ワークスペースをファイルシステム階層のどこに配置するかによって変わります。一方、ワークスペースディレクトリの下に置かれるファイルシステムは、オリジナルのワークスペースのものとまったく同じです。

親子関係

あるワークスペースからファイルをコピーして別のワークスペースを作成すると、それらのワークスペースの間には親子関係が築かれます。すなわち、オリジナルのワークスペースは新たに作成されたワークスペースの親であり、新しいワークスペースはその子ということになります。この方法により、ワークスペース管理ツールの任意のワークスペースからファイルを取得することができます。また、ワークスペースはいくつでも子を持つことができます。親ワークスペースから何をコピーするかは、コピーする時点に決定します。親からそのすべての内容をコピーすることもでき (この場合、親と子はまったく同じ内容となります)、必要な部分だけをコピーすることもできます。このように、親ワークスペースから子ワークスペースにファイルをコピーするときに行うトランザクションを「ブリングオーバー」と呼びます。

注 -

ブリングオーバートランザクションを使用して、存在しないワークスペースにファイルをコピーしようとすると、新たに子ワークスペースが作成されて、そのワークスペースにファイルがコピーされます。これは、ブリングオーバートランザクションの特殊な処理で、「作成ブリングオーバー」トランザクションと言います。また、「更新ブリングオーバー」トランザクションを使用すると、既存の子ワークスペースの内容を更新できます。

このような親子関係は、プロジェクトデータが親と子の間でのみやりとりされる点が特殊です。子ワークスペースに格納されているファイルはすべて、親ワークスペースから取り込まれたものであるか、あるいは子ワークスペース内で作成されたものです。子ワークスペースで開発とテストが完了すれば、そのワークスペースで変更あるいは追加したファイルを親ワークスペースに戻すことができます。また、変更したファイルが親ワークスペースに存在する場合には、それらを別の子ワークスペースにコピーしたり、その親ワークスペースの 1 つ上の親ワークスペースに渡すことも可能です。子ワークスペースから親ワークスペースにファイルをコピーするときに行うトランザクションを「プットバック」トランザクションと言います。

注 -

子ワークスペースが別のワークスペースの親でない場合は、新しいファイルをその子ワークスペースからコピーすることもできます。

ワークスペースの階層は、ブリングオーバートランザクションを行なっていくつかの子ワークスペースを作成することによって形成されます。したがって、親子ワークスペースの階層を見ると、プロジェクト全体でデータがどのように移動するかを知ることができます。

次に挙げる例では、あるワークスペースで最初にプロジェクトが作成された後、ブリングオーバートランザクションによって 3 層のワークスペース階層が作成されています。オリジナルのワークスペースは統合ワークスペースの親と見なされ、逆に統合ワークスペースはオリジナルのワークスペースの子と見なされます。この例では、図 2-3 に示すように開発者 1、開発者 2、開発者 3 の 3 名の開発者がそれぞれ作成ブリングオーバートランザクションを使用して、統合ワークスペースから子ワークスペースを作成し、これによって 3 層のワークスペース階層が形成されています。

図 2-3 作成ブリングオーバーによるワークスペース階層の作成

この階層では、開発者 1 のワークスペースから開発者 2 と開発者 3 がそれぞれ所有する「兄妹」ワークスペースにファイルをコピーすることができます。図 2-4 に示すように、開発者 1 はプットバックトランザクションを使用して自分のワークスペースから変更したファイルを共通の親にコピーし (１)、開発者 2 と開発者 3 が更新ブリングオーバートランザクションを使用して親からそれぞれのワークスペースにファイルをコピーします (２)。

図 2-4 ワークスペース間でのファイルのコピー

親子関係の変更

ワークスペースの親子関係は変更できます。つまり、子ワークスペースの親を別の親ワークスペースに変更できます。親子関係の変更は次に示すような場合に必要になります。

ワークスペース階層の編成を変更する場合
新しいプロジェクト階層 (新しい最上位ワークスペース) を作成する場合
機能を新しいリリースに移動する場合
複数のリリースにバグ修正をする場合

詳細は、「ワークスペースの親子関係の変更」を参照してください。

Codemgr_wsdata ディレクトリ

ワークスペース管理ツールによって管理されている各ワークスペースには、Codemgr_wsdata という名前のディレクトリが存在します。このディレクトリは、ワークスペースの最上位ディレクトリのサブディレクトリであり、ワークスペース管理ツールがその処理内容の記録やデータの格納に使用するテキストファイルが格納されます。これらのファイルは、標準的なテキストエディタなどのユーティリティを使用して、表示したり変更を加えたりすることができます。詳細は、「ワークスペースのメタデータディレクトリ」を参照してください。

ファイルの修正

ワークスペース管理ツールのワークスペースは SunOS ファイルシステム内のディレクトリにすぎません。そのため、ワークスペース内のファイルやディレクトリには通常のツールやユーティリティをすべて利用できます。通常の開発業務で行われている編集、コンパイル、デバッグというプロセスは、ワークスペース管理ツールを利用している場合も変わりません。

ワークスペース間でのファイルのコピー

子ワークスペース内でファイルに修正を加えテストを完了した後は、このファイルを同じプロジェクトのほかの開発者および最終的には統合/リリース用のワークスペースに引き渡す必要があります。

プロジェクトに関わる各開発者は、最新のデータを必要とします。プロジェクトのある部分で、あるモジュールに対して行なった修正が、プロジェクトの別の部分で行われる別のモジュールのテストに影響を与えることがあります。また、同じモジュールまたは密接な関係にあるモジュールの開発に携わる開発者同士では、最新のデータを持つことのほかに、情報を共有することが大切です。

新たに修正したファイルを、親子の間あるいはワークスペース階層内の必要な箇所に反映して、ワークスペースの整合性を維持する必要があります。こうしたデータの受け渡しをどのタイミングで行うかは、開発者自身が決定します。

プットバックトランザクションとブリングオーバートランザクションは通常、個別にファイルを指定しなくても済むように、ファイルのグループに対して実行されます。このためワークスペース管理ツールには、論理的に一緒にコピーすべきファイルをグループ化するための方法が用意されています。

たとえば、次のようなものをグループ化することができます。

ディレクトリ
特定のプログラムを構築するために必要なファイル
子ワークスペースの全ファイル

ワークスペース間でのプットバックおよびブリングオーバートランザクションの対象となるファイルをグループ化する具体的な方法については、第 7 章「ワークスペース間でのファイルのコピー」を参照してください。

ブリングオーバーおよびプットバックのトランザクションは必ず子ワークスペース内から実行します。これらのトランザクションは、子ワークスペースの視点から見た名前が付けられています。

SCCS ファイル

ブリングオーバーおよびプットバックのトランザクションでは、実際にはソースファイルが SCCS デルタから得られ、SCCS デルタ ID (SID) で識別されます。ファイルをプットバックあるいはブリングオーバートランザクションでコピーするとき、ワークスペース管理ツールはそのファイルの SCCS 履歴ファイル (ファイル名の先頭に s. が付くのでエスドットファイルとも呼ばれる) を操作しています。

あるワークスペースから別のワークスペースにファイルをコピーする場合、ワークスペース管理ツールは、SCCS 履歴ファイルをどのように操作して該当ファイルを得るかを決定します。ターゲットワークスペースに該当ファイルが存在しない場合には、ソースワークスペースからターゲットワークスペースにその履歴ファイルを単にコピーします。もっと複雑なケース、たとえばファイル (および SCCS 履歴ファイル) がソースとターゲットの両方に存在するような場合には、そのファイルのデルタ、管理履歴、コメント履歴を維持するように SCCS 履歴ファイルをマージしなければなりません。

以降、「ファイル」という表現が、実際には SCCS の get コマンドによって最新およびそれ以前のデルタから得られたファイルと、元になる SCCS 履歴ファイルの両方を指していることを念頭に置いてください。ワークスペース間でファイルをコピーする場合には、SCCS 履歴ファイルもそれに合わせて適宜調整されます。

ブリングオーバーおよびプットバックのトランザクション

更新ブリングオーバーあるいはプットバックトランザクションが起動された場合、ワークスペース管理ツールは指定された処理を行う前にいくつかの事柄を決定しなければなりません。あるワークスペースから別のワークスペースにファイルを無差別にコピーすると、保持しておきたい作業途中のファイルがコピー元のファイルで置き換えられてしまう可能性があります。そこでワークスペース管理ツールは、コピー対象として指定されたすべてのファイルをチェックして、コピー先ワークスペース内の各対応ファイルとの関係を保つことができるかどうかを判断します。

たとえば、ある開発者があるファイルを最後に自分のワークスペースにコピーした後、親ワークスペース内でこのファイルに変更が加えられた場合 (おそらく別の子ワークスペースからプットバックされた) を考えてみましょう。この開発者は自分のワークスペース内の同じファイルに独自の変更を加えています。ここで、このファイル (またはこのファイルを含むファイルグループ) を親ワークスペースにそのまま戻すと、親ワークスペース内の同じファイルの改訂版が書き直されてしまうため、ワークスペース管理ツールはこの開発者からのプットバックトランザクションの実行を許可しません。このような場合、ワークスペース管理ツールは、この開発者からのプットバックトランザクション実行要求を拒否し、変更の衝突が存在することを通知します。

プットバックおよび更新ブリングオーバーのトランザクションの実行が拒否されると、該当グループに含まれるファイルはすべて、衝突が存在しなくてもコピーされません。

開発者のワークスペース内のファイルと親ワークスペース内の対応ファイルとの間の衝突は、親ワークスペースの整合性を常に保つために、必ず開発者側の (子) ワークスペース内で解決してください。

衝突を解決するためには、まず更新ブリングオーバートランザクションを使用して、衝突の存在するファイルを親ワークスペースから子ワークスペースにコピーします。次に、ファイルマージを使用して開発者側の変更をこのファイルにマージした後、衝突が解決されたファイルを親ワークスペースにプットバックします。

表 2-2 衝突が発生した場合の処理


	開発者 A と B は同じファイルをそれぞれのワークスペースにコピーします。
	開発者 B はこのファイルに変更を加え、変更したファイルを親ワークスペースにプットバックします。
	開発者 A は同じファイルに独自の変更を加えた後、それを親ワークスペースにプットバックしようとしますが、この時点で親との間で衝突が存在するため、ワークスペース管理ツールによって拒否されます。
	ワークスペース管理ツールによって、親と子の間に変更の衝突が存在することが通知されます。開発者 A はここで、親ワークスペースから最新の該当ファイルを自分のワークスペースにブリングオーバーしてきます (実際には、SCCS 履歴ファイルがマージされます)。
	変更内容の衝突を解決してから、結果のファイルをテストし、問題がなければこれを親ワークスペースにプットバックします。

親および子ワークスペース内の対応ファイルの関係

親ワークスペースと子ワークスペースにそれぞれ存在する対応ファイル間には、4 種類の関係が考えられます。先述の例では、このうちの 1 つについてのみ説明しました。双方のファイルがどのような関係にあるかによって、プットバックあるいは更新ブリングオーバーのトランザクションを使用してファイルをコピーしようとしたときにワークスペース管理ツールが行う処理が異なります。ここでは、この 4 種類の関係と、それぞれの場合でワークスペース管理ツールが行う処理について説明します。

ケース 1

親ワークスペースのファイルと子ワークスペースのファイルが両方とも、それらが親に戻されて以来、あるいは子に渡されて以来、まったく変更されていない場合。

このケースでは、プットバックトランザクションでも更新ブリングオーバートランザクションでも、ワークスペース管理ツールは何も処理を行いません。このファイルは、親と子の間で内容がまったく同じです。

ケース 2

指定されたファイルは、親から子または子から親へコピーされて以来変更されていなかったが、子の対応するファイルには変更が加えられた場合。

このケースでは、プットバックトランザクションで子から親にファイルをコピーすると、親に存在する対応ファイルが子からプットバックされたファイルに置き換えられ、変更されているファイルが更新されます。以後、ほかの子はこの新しいデータを受け取ることができます。また、この親の 1 つ上の親ワークスペースもこのデータを受け取ることができます。

このケースで更新ブリングオーバーコマンドを実行しようとしても、子のファイルの内容が古い親ファイルの内容に置き換えられてしまうことになるため、何も処理はされません。

ケース 3

親ワークスペースの 1 つまたは複数のファイルが変更されたが、子ワークスペースの対応するファイルには変更がなかった場合。

このケースでは、子が親にプットバックしようとしているファイルは、最後にこのファイルが子にブリングオーバーされた後、おそらくほかの開発者 (子ワークスペース) によって親が変更されています。一方、子の該当ファイルには変更はありません。

ワークスペース管理ツールがプットバックトランザクションの実行時にこの状況を検知した場合、子ワークスペースが更新ブリングオーバートランザクションによって更新されるまで親ワークスペースを更新することはできません。子ワークスペースで変更していないファイルにこのような変更が加えられている場合でも、子の側で行なった変更が反映されない可能性があります (ファイルはグループでコピーする、という点を思い出してください)。この場合には、プットバックトランザクションは実行されず、その状況が通知されます。子ワークスペースを更新するために更新ブリングオーバートランザクションを実行するのは、その子ワークスペースの所有者である開発者が行います。

ケース 4

親と子の双方で対応するファイルに変更が存在した場合。

これは最も複雑なケースです。ワークスペース管理ツールは、プットバックトランザクションで子から親にファイルを戻すと、すべての変更を正しく反映することができなくなるため、このトランザクションの実行を許可しません。同様の理由から、親から子にファイルをコピーすることも許可しません。

すでに説明した 3 つのケースの場合と同様、ワークスペース管理ツールはプットバックトランザクションを禁止し、その状況を開発者に通知します。開発者がブリングオーバートランザクションで子ワークスペースを更新しようとすると、ワークスペース管理ツールは子のファイルが変更されていることを検出します。つまり、このままトランザクションを実行してしまうと、子ワークスペースで行なった作業内容がすべて失われてしまうということです。この場合、ワークスペース管理ツールは子ワークスペース内の該当ファイルの、親と子の双方の SCCS 履歴ファイルをマージします。

ワークスペース管理ツールはこれらの SCCS 履歴ファイルを子ワークスペース内でマージします。その際、子ワークスペース内で作成された SID は変更され、親から受け継いだ現在のデルタツリーから枝分かれした SCCS ブランチに置かれます。ただし、何も変更がなかったものとして子ワークスペース内で引き続きファイルに対する作業が行えるように、子の SCCS バージョンツリーはその後の追加デルタに関してデフォルトの設定のまま変わりません。マージプロセスでは、衝突が存在するファイルを開発者側の意向で自由にマージできるように、必要なデルタがすべて SCCS 履歴ファイルに挿入されます。また、SCCS デルタ履歴全体が保持されるため、SCCS のコメントがこのプロセスで変更されることもありません。

親と子の間でのファイルの衝突はまだ完全に解決されたわけではありません。子の側で作成されたデルタを持つブランチでも変更作業を続けることは可能だからです。ここで変更作業が続けられた場合には当然、新しいデルタはこのブランチに追加されていきます。しかし、衝突が存在するファイルが含まれているファイルグループを親に戻すためには、この衝突を解決しておかなければなりません。衝突の解決については、「衝突の解決」で説明します。

まとめ

この節で説明してきた親子関係の 4 つのケースそれぞれについて、プットバックトランザクション実行時にワークスペース管理ツールが行う処理を、表 2-3 にまとめます。表 2-4 は同様に、ブリングオーバートランザクションを実行した場合の処理をまとめたものです。

表 2-3 ブットバック実行時の処理


ケース	親のファイル	子のファイル	ワークスペース管理ツールの処理
1	変更なし	変更なし	なし
2	変更なし	変更あり	親のファイルを更新
3	変更あり	変更なし	プットバックを中止し、開発者に通知
4	変更あり	変更あり	プットバックを中止し、開発者に通知

表 2-4 ブリングオーバー実行時の処理


ケース	親のファイル	子のファイル	ワークスペース管理ツールの処理
1	変更なし	変更なし	なし
2	変更なし	変更あり	なし
3	変更あり	変更なし	子を更新 (SCCS ファイルを変更)
4	変更あり	変更あり	SCCS 履歴ファイルをマージし、衝突の存在を開発者に通知

衝突の解決

プットバックトランザクションの実行時に、ワークスペース管理ツールは、ファイルが最後に子から親に戻されてから、あるいは親から子に渡されてから親ワークスペース内のファイルが変更されていることを検出することがあります。この場合ワークスペース管理ツールは、その変更内容がファイルのコピーによって消されてしまわないようにプットバックトランザクションを中止し、変更内容の衝突が存在する可能性のあることを開発者に通知します。

通常、子ワークスペースの所有者は、親のファイルが変更されている場合、これを自分のワークスペースにコピーすることによって自分のファイルを更新しようとします。この更新ブリングオーバートランザクションの実行時に、子ワークスペース内の対応ファイルも最後に親からコピーした後変更されていることが判明すると、衝突が存在するものと判断されます。

親と子の両方で、対応する両方のファイルに別々の変更が加えられていると衝突が発生します。仮にワークスペース管理ツールが一方のファイルで他方のファイルを上書きしてしまうと、他方の変更内容は失われてしまいます。したがって、そのファイルが宛先にコピーされる前に、開発者はそのような衝突をすべて解決しておかなければなりません。

更新ブリングオーバートランザクションの実行時に衝突を検出すると、ワークスペース管理ツールは次のような処置をとります。

子ワークスペース内で、衝突の存在するファイルに関する親と子それぞれの SCCS 履歴ファイルをマージします。

その衝突の存在を該当開発者に通知します。

開発者の衝突解決の作業を支援します。

注 -
衝突解決の作業はすべて、子ワークスペース内で行なってください。

ほとんどの衝突の場合、次のような方法で衝突を解決できます。

衝突が解決されたバージョンとして親から子に最新デルタを取り込みます。

衝突が解決されたバージョンとして子からの最新デルタを受け入れます。得られたファイルは、衝突解決プロセスを経たバージョンであるため、プットバックトランザクションが親ワークスペース内で中止されることはなくなります。

親の最新デルタを子の最新デルタとマージします。

ワークスペース管理ツールには、衝突を解決するための機能が用意されていますが、その作業自体は開発者自身が行わなければなりません。衝突の解決方法についての詳細は、第 8 章「衝突の解決」を参照してください。