Sun WorkShop TeamWare ユーザーズガイド ホーム目次前ページへ次ページへ索引


第 12 章

Sun WorkShop TeamWare のアーキテクチャー

この章では、Sun WorkShop TeamWare がワークスペースとファイルを追跡するのに使用する、基本となるファイルについて説明します。また、ワークスペース間でファイルがコピーされたり衝突が解決されたりしたときに、ワークスペース管理ツールがどのように SCCS 履歴ファイルを操作するかについても説明します。

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

ワークスペースのメタデータディレクトリ

ワークスペース管理ツールのワークスペースは、その最上位ディレクトリに Codemgr_wsdata というディレクトリを含むディレクトリです。ワークスペース管理ツールは、Codemgr_wsdata ディレクトリにワークスペースに関するデータ (メタデータ) を記録します。ワークスペース管理ツールのコマンドは、Codemgr_wsdata ディレクトリの有無に基づいて、ディレクトリがワークスペースであるかどうかを判断します。

ワークスペース管理ツールには、Codemgr_wsdata ディレクトリ内に格納されている情報を管理するために必要なツールが用意されています。推奨しませんが、特定のファイルを手作業で編集することが必要になる場合があります。ただし、その場合も、編集する個々のファイルの形式を保つように注意する必要があります。表 12-1 に、Codemgr_wsdata ディレクトリに含まれるファイルとディレクトリの概要を示します。これらのファイルの形式については、各ファイルのマニュアルページを参照してください。

表 12-1   Codemgr_wsdata メタデータディレクトリの内容  
ファイル /
ディレクトリ名
説明
access_control ワークスペースに対してどのユーザーがワークスペース管理ツールのトランザクションとコマンドを実行できるようにするかを制御する情報が含まれています。ワークスペースが作成されると、デフォルトのアクセス制御ファイルが作成されます。第 4 章および 「access_control ファイル」を参照してください。
args ファイルやディレクトリ、FLP 引数のリストを含んでいます。ワークスペース管理ツールのブリングオーバーおよびプットバックトランザクションコマンドによって管理されます。最初、このファイルには、ワークスペースが作成時に指定された引数が含まれます。以降のブリングオーバーまたはプットバックトランザクションでユーザーが引数を明示的に指定すると、args ファイル内にすでに存在する引数よりも新しい引数が広範囲かどうかが判断され、より広範囲である場合は、古い引数は新しい引数に置き換えられます。「独自のブリングオーバー / プットバック用ファイルリストの作成」を参照してください。
backup/ ワークスペース管理ツールがブリングオーバーやプットバックトランザクションを取り消すときに使用する情報を保存します。「ワークスペースに対する変更の取り消し」を参照してください。
children ワークスペースの子ワークスペースのリストです。作成ブリングオーバートランザクションを実行すると、このファイルに子ワークスペース名が書き込まれます。ワークスペース管理ツールは、このファイルを参照して、子ワークスペースのリストを取得します。ワークスペースを削除、移動したり、ワークスペースの親を変更したりすると、親の children ファイルが更新されます。
conflicts ワークスペース内で、現在、衝突状態にあるファイルのリストです。衝突とその解決方法については、第 6 章を参照してください。
description ユーザーがワークスペースに付けた名前と詳細な説明が含まれるファイルです。「ワークスペースに分かりやすい名前を付ける」を参照してください。
Freezepoints/ 自動フリーズポイントを設定したときに作成されます。「フリーズポイントの自動作成」を参照してください。
history ワークスペースに関係するトランザクションおよび更新ファイルの履歴です。「ワークスペースの履歴表示」を参照してください。
locks ブリングオーバー、プットバック、取り消しトランザクションの実行中に、ワークスペース管理ツールはワークスペースをロックして、その整合性を保ちます。このロック情報は、各ワークスペースの locks ファイルに記録されます。ワークスペース管理ツールは、ワークスペースに対する処理を開始する前に、このファイルを参照し、ロックの有無を確認します。「ワークスペースのロックの解除」を参照してください。
nametable SCCS ファイル名 (ワークスペースを基準にした相対パス名) と 4 つの 32 ビット 16 進ワードで表現された一意の番号からなるテーブルです。このテーブル内の各エントリは改行文字で区切られています。ワークスペース管理ツールは、ブリングオーバーおよびプットバックでこのファイルを使用し、名前が変更されたファイルの処理が高速に行われるようにします。このファイルが見つからない場合、ワークスペース管理ツールは次のプットバックまたはブリングオーバートランザクションで自動的にファイルを作成します。「ファイル名の変更とファイルの移動、削除」を参照してください。
notification ワークスペース管理ツールは、このファイルを参照することによって、ワークスペースに関係するイベントを検出し、そのイベントに対する応答として電子メールを送信します。「他のユーザーへのトランザクションの実行通知」を参照してください。
parent 作成ブリングオーバートランザクションで作成される、ワークスペースの親ワークスペース名が含まれるファイルです。また、ワークスペースがワークスペース作成コマンドで作成され、親を持っていない場合は、親の変更コマンドを実行したときにも作成されます。ワークスペース管理ツールは、このファイルを参照してワークスペースの親を認識します。ワークスペースを削除や移動、またはワークスペースの親を変更すると、子の parent ファイルが更新されます。
putback.cmt 最後にブロックされたプットバックトランザクションのコメントを一時的に保持するキャッシュです。プットバックトランザクションがブロックされると、コメントが廃棄されます。ワークスペース管理ツールはこのファイルにコメントを書き込むことによって、トランザクションを再実行したときに元のテキストを取り出せるようにします。


ワークスペース管理ツールのデフォルト値ファイル

「ツール属性」ウィンドウを使用してワークスペース管理ツールの動作の設定を変更して、「適用」ボタンをクリックすると、その変更をホームディレクトリの実行時構成ファイルに保存できます。ワークスペース管理ツールは、起動されたときにその実行時構成ファイルを参照し、その中の新しい設定をデフォルト値として使用します。

「ツール属性」ウィンドウの「ワークスペース管理」や「ブリングオーバー/プットバック」タブで行なった変更は、~/.codemgrtoolrc ファイルに書き込まれます。このファイルは、XWindows のリソースファイルです。

「ツール属性」ウィンドウの「衝突解決」タブで行なった変更は、~/.codemgr_resrc という実行時構成ファイルに書き込まれます。

環境変数を使用して、デフォルトで読み込むワークスペースを制御できます (「環境変数の設定」を参照)。デフォルトでブリングオーバー / プットバックするファイルのリストを作成することもできます (「独自のファイルリストの作成」を参照)。

access_control ファイル

第 4 章では、ワークスペースに対してどのユーザーがどのトランザクションを実行できるかを制御する方法を説明しました。「アクセス制御」タブでアクセス権を設定すると、access_control ファイルにその情報が書き込まれます。表 12-2 は、ワークスペースを作成したときの access_control ファイルのデフォルトの内容を示しています。

表 12-2   デフォルトのアクセス権設定
トランザクション デフォルトのアクセス権
bringover-from 全ユーザー
bringover-to 作成者
putback-from 全ユーザー
putback-to 全ユーザー
undo 全ユーザー
workspace-delete 作成者
workspace-move 作成者
workspace-reparent 作成者
workspace-reparent-to 全ユーザー


access_control ファイルを手作業で編集し、ワークスペースに対するアクセスを許可するユーザーを制御できます。表 12-3 に、ワークスペースに対するアクセスを制御するために指定できるすべての値と、その意味をまとめます。

表 12-3   ワークスペースに対するアクセス制御値
意味
@engineering ネットグループ engineering のユーザー全員が、このトランザクションを実行できます。
-@engineering ネットグループ engineering のユーザーは、このトランザクションを実行できません。
"-" は否定を意味します。
@special -user2 @engineering ネットグループ special および engineering のユーザーは、このトランザクションを実行できます。ただし、user2 は実行できません (user2special ネットグループに属してない場合)。"-" は否定を意味します。
user1 user2 ユーザー user1user2 は、このトランザクションを実行できます。
"-" どのユーザーも、このトランザクションを実行できせん。
作成者 ワークスペースの作成者だけ、このトランザクションを実行できます。実際には、作成者のログイン名が示されます。
(エントリなし) ユーザー全員がこのトランザクションを実行できます。


ワークスペース管理ツールによるファイルの
マージ

この節では、分岐の概念などを含め、読者が SCCS について理解していることを前提に説明をしています。分岐については、「ファイルの履歴 (デルタ、分岐、バージョン)」を参照してください。SCCS についての詳細は、Solaris の『プログラミングユーティリティ』を参照してください。

ブリングオーバーやプットバックトランザクションでは、転送元 (ソース) ファイルは SCCS デルタから得られるファイルで、SCCS デルタ ID (SID) によって識別されます。これらのトランザクションによってファイルがコピーされた場合、ワークスペース管理ツールプログラムは、そのファイルの SCCS 履歴ファイル (s ドットファイル) を処理する必要があります。

ブリングオーバーやプットバックトランザクションによって転送元ワークスペースから転送先ワークスペースにファイルをコピーした場合、その処理は、表面的にはファイルが 1 つ転送されただけのように見えます。しかし、実際には、そのファイルに関するすべての SCCS 情報 (デルタやコメントなど) が、転送先の SCCS 履歴ファイルにマージされます。転送元の情報を転送先の履歴ファイルにマージすることによって、現在のバージョン (デルタ) を作成して、ファイルのデルタとコメント履歴全体を利用できるようになります。ただし、これはファイルが転送先ワークスペースに存在する場合に限ります。存在しない場合は、転送元ワークスペースの履歴ファイルのすべての全内容が転送先ワークスペースにコピーされます。

衝突していないファイルのマージ

転送先ワークスペースのファイルを更新する場合 (つまり、ブリングオーバーまたはプットバックトランザクションの転送元のファイルが変更されていて、転送先では変更されていない場合) は、新しいデルタが転送先の履歴ファイルに追加されます。この場合、SCCS 履歴ファイルを転送元から転送先にコピーせずに、マージするのは、転送先の履歴ファイルに格納されているフラグやアクセスリストなどの管理情報が上書きされるのを防ぐためです。

ファイルマージを行う際、ワークスペース管理ツールはデルタ履歴の分岐箇所を判別し、その分岐の発生以後に転送元ワークスペースで作成されたデルタのみを転送先ワークスペースに追加します。履歴の分岐箇所を特定するために、親と子の履歴ファイルのデルタテーブルを比較します。この比較に使用される情報には、該当デルタがいつ誰によって作成されたかといったデータやコメントが含まれています。

図 12-1 に、プットバックトランザクションで子ワークスペースのデルタ 1.3 と 1.4 を親ワークスペースの SCCS 履歴ファイルに追加する例を示します。


図 12-1   転送先ワークスペース内の変更されていないファイルの更新

衝突しているファイルのマージ

親と子の間でファイルをコピーする場合、それぞれのファイルのバージョンが最後に更新されてから変更されていることがあります。このような場合、親と子のファイルが「衝突」していると言います。

ファイルが衝突していると、ワークスペース管理ツールはそれぞれのファイルに加えられた変更の矛盾をユーザーが効率的に解決できるように支援し、それらのファイルのデルタ、管理情報、コメント履歴を保持しようとします。ワークスペース管理ツールは、親の SCCS デルタを子の履歴ファイルにマージします。次に、衝突解決トランザクションによって、子の側でこの衝突を解決します。衝突解決についての詳細は、「ワークスペース内での衝突の解決」を参照してください。

ファイルマージによるデルタの追跡方法

この節では、1 つの統合ワークスペースとそれぞれ別の開発者が所有する 2 つの子ワークスペースを使用した例を紹介します。2 人の開発者はそれぞれ、統合ワークスペースから同じファイルをコピーし、このファイルに独自の変更を加えています。この例で、衝突が発生したときに、それらを解決するためにワークスペース管理ツールが SCCS ファイルをどのように処理するかを説明します。説明図については、次の点に留意してください。

開発者はそれぞれ、ブリングオーバートランザクションにより統合ワークスペースから同じファイルをコピーします。このファイルは両開発者のワークスペースでは新規のものであるため、 SCCS 履歴ファイルが両ワークスペースにコピーされます。統合ワークスペースは、両開発者が使用する親ワークスペースです。

開発者 B は、このファイルに変更を加えて、 2 つの新しいデルタ 1.3 と 1.4 を作成した後、ファイルを統合ワークスペースに戻します (プットバックトランザクション)。このときワークスペース管理ツールは、2 つの新しいデルタを親の SCCS デルタツリーに追加します。

アクセスリストなどの管理情報を保持するため、転送先ワークスペース側の SCCS 履歴ファイルが転送元ワークスペース側のファイルに置き換えられることはありません。新しいデルタが転送先の SCCS 履歴ファイルに追加されます。


一方、開発者 A も、コピーしてきた同じファイルに独自の変更を加え (3 つの新しいデルタ 1.3、1.4、1.5 を作成)、ファイルを統合ワークスペースに戻そうとします。

ファイルが衝突しているので 、ワークスペース管理ツールは、開発者 A のプットバックトランザクションの実行要求をブロック (拒否) します。もし、ここでプットバックトランザクションの実行を許可すると、開発者 B がプットバックした変更が失われてしまいます。開発者 A はプットバックの前に、開発者 B による変更内容を自分のファイルに取り込む必要があります。


開発者 A は、この時点で開発者 B による変更を含むファイルを統合ワークスペースから自分のワークスペースにコピーします。このとき、開発者 B によって作成されたデルタが、開発者 A の SCCS 履歴ファイルに追加されます。

親からコピーされたデルタツリーが子の側で変更されることはありません。子で作成された新しいデルタが SCCS 分岐として、子と親に共通の最後のデルタに追加され、それぞれ新しい SID が割り当てられます。これらのデルタには、デルタの分岐点から SID を生成する SCCS 分岐番号割り当てアルゴリズムによって新しい番号が付けられます。この例では、分岐は SID 1.2 に追加され、最初のデルタの番号は 1.2.1.1 になります。また、子の側で作成された最後のデルタ (1.2.1.3、分岐になる前の 1.5) はその後もデフォルトのデルタとして扱われます。したがって、開発者 A が衝突の解決以前に子ワークスペースで作成した新しいデルタはすべて、子の分岐に追加され、親の基幹ツリーには追加されません。


開発者 A は、自分のワークスペースで衝突解決トランザクションを使用して衝突を解決します (衝突解決についての詳細は、「ワークスペース内での衝突の解決」を参照)。開発者 A は衝突解決トランザクションを使用して、SID 1.2.1.3 と 1.4 で表わされるそれぞれのファイルバージョンをどのようにマージするかを決定します。開発者 A が変更を適用すると、衝突解決トランザクションは新たにマージされた内容を新しいデルタ (1.5) に書き込みます。


以上でファイルの衝突が解決されたので、開発者 A は自分の最新のファイルを統合ワークスペースにプットバックできます。このとき、分岐と新たに作成されたデルタは、統合ワークスペースの SCCS 履歴ファイルに追加されます。


開発者 B は、自分のワークスペースでファイルに別の変更を行います。この結果、デルタ 1.5 が作成されます。続いて、この新しい変更を統合ワークスペースにプットバックしようとしますが、開発者 A がその前に統合ワークスペースに戻した新しいデルタ 1.5 と内容が異なるため、このトランザクションの実行は許可されません。


開発者 B は、開発者 A が統合ワークスペースに戻した変更されたファイルを自分のワークスペースにブリングオーバーします。ここで、このファイルのデルタは、ワークスペース管理ツールによって開発者 B のワークスペースの SCCS 履歴ファイルに追加され、番号が付けなおされます。


前述の例と同様に、ワークスペース管理ツールは、開発者 B が作成したデルタを、基幹デルタツリーの最新の共通デルタに分岐として追加し、それに応じて番号を付けなおします。1.5 が 1.4.1.1 になります。1.4.1.1 は、デフォルトのデルタのままです。衝突が解決される以前に開発者 B のワークスペースで新たに作成されたデルタはすべて、この分岐に追加されます。


開発者 B は、衝突解決トランザクションを使用して、1.5 と 1.4.1.1 との相異をマージして衝突を解決し、新しいデルタ 1.6 を作成します。


上記のマージ例は、統合ワークスペースと 2 つの子ワークスペースがあって、子ワークスペースをそれぞれ異なる開発者が所有しているときに行われる処理を示しています。2 人の開発者は統合ワークスペースから同じファイルのコピーをブリングオーバーして、それぞれにファイルを変更しました。変更をプットバックしようとすると、衝突が発生します。ワークスペース管理ツールは変更が上書きされないようにデルタを管理し、SCCS 履歴ファイルを操作して、ファイルの履歴が正確で完全であるようにします。

SCCS マージ可能 ID について

この節では、SCCS マージ可能 ID (SMID) が必要な理由、SCCS デルタ ID (SID) から SMID への変換方法、および SMID から SID への変換方法について説明します。

SMID を使用すると、SID の変更に関係なく、すべてのデルタを一意に識別できます。SMID は、Xerox Secure Hash Function を使用して生成される番号です。フリーズポイントツールを使用してフリーズポイントファイルを作成すると、SCCS 履歴ファイル内の現在のデルタとルートデルタの両方について SMID が計算されます。この 2 つの値を使用することにより、フリーズポイントツールでは、SID が変更された場合でもファイル内のデルタを識別できます。

SMID が必要な理由

ワークスペース管理ツールは、更新ブリングオーバートランザクションの実行中にファイルの衝突 (ファイルが親ワークスペースと子ワークスペースの両方で変更された状態) を検出すると、親ワークスペースの新しいデルタを、子ワークスペースの SCCS 履歴ファイル内にマージします。このマージ処理では、子ワークスペースで作成されたデルタは、親子両方のデルタに共通するデルタ (共通の祖先) からの SCCS 分岐に移動します。

ワークスペース管理ツールは、子デルタを分岐に移動する際にその SID を変更します。フリーズポイントファイルでのデルタの識別に SID を使用している場合は、この移動により、フリーズポイントファイル内の情報が無効になります。このため、衝突する SCCS 履歴ファイルをマージした後は、デルタの識別に SID を使用できません。

SMID と SID の変換

SID から SMID への変換および SMID から SID への変換には、freezept コマンドの sid サブコマンドおよび smid サブコマンドを使用します。これらの ID の変換は、デルタを追跡するための独自のスクリプトやプログラムを作成する場合に使用すると便利です。

SID から SMID への変換

SID から SMID への変換には、freezept smid コマンドを使用します。構文は次のとおりです。

freezept smid [-w workspace][-r SID][-a] filename

example% freezept smid -r 1.38 module.c
SID 1.38 = SMID "f5b67794 705f0768 a89b1f4 588de104"

example% freezept smid -a bringover.1
SID 1.1 = SMID "b05b0a2f 1db5246e 1a466014 707e38f5"
SID 1.2 = SMID "d6s5c61f 5634f0ef 9847a080 d0d7b212"
SID 1.2 = SMID "e31acdd5 6c1232e2 9e81c287 1edb2f41"
SID 1.3 = SMID "c34c91b4 a818622a 2457356a 489b2728"
SID 1.4 = SMID "98c0fd8d 889563fb cf722c2b 6afc9636"
SID 1.5 = SMID "ble24be3 752fec3e df2d2717 a9b3f1fa"
SID 1.6 = SMID "2b93d39 1ea2f6ba 9814320c bc609acb"
SID 1.7 = SMID "1db7d640 42b0f009 35c60d7b b230bd85"
SID 1.8 = SMID "906dfe9a ca7e2d6c a64da5be 4baef254"

SMID から SID への変換

SMID から SID への変換には、freezept sid コマンドを使用します。構文は次のとおりです。

freezept sid [-w workspace][-m "SMID"][-a] filename

example% freezept smid -m "64fdd0df de9d7dd de75812 23da96aa"  
module.c
SMID "f5b67794 705f0768 a89b1f4 588de104" = SID 1.36

example% freezept smid -a bringover.1
SMID "b05b0a2f 1db5246e 1a466014 707e38f5" = SID 1.1
SMID "d6s5c61f 5634f0ef 9847a080 d0d7b212" = SID 1.2
SMID "e31acdd5 6c1232e2 9e81c287 1edb2f41" = SID 1.2
SMID "c34c91b4 a818622a 2457356a 489b2728" = SID 1.3
SMID "98c0fd8d 889563fb cf722c2b 6afc9636" = SID 1.4
SMID "ble24be3 752fec3e df2d2717 a9b3f1fa" = SID 1.5
SMID "2b93d39 1ea2f6ba 9814320c bc609acb" = SID 1.6
SMID "1db7d640 42b0f009 35c60d7b b230bd85" = SID 1.7
SMID "906dfe9a ca7e2d6c a64da5be 4baef254" = SID 1.8
SMID "77481e8a 61542339 cc28f532 e5fc6389" = SID 1.9
SMID "cb97c9a6 d0342cf6 19b7b743 2436ca1c" = SID 1.10
SMID "46de4131 b96b9973 93958a07 b960074c2 = SID 1.11


サン・マイクロシステムズ株式会社
Copyright information. All rights reserved.
ホーム   |   目次   |   前ページへ   |   次ページへ   |   索引