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 に、ワークスペースに対するアクセスを制御するために指定できるすべての値と、その意味をまとめます。
ワークスペース管理ツールによるファイルの
マージこの節では、分岐の概念などを含め、読者が 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 デルタツリーに追加されるポイント) は、下にシンボルが接続されていない線で表しています。
- バージョン管理ツールを使用することによって、ここで示しているのと同じような形式で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) に書き込みます。
- 新しいデルタ 1.5 をこのように丸で囲んで表現しているのは、これが開発者 A によって作成されたものであることを示すためです。
- 新たに作成されたデルタは、この時点で、開発者 A が次に行う変更内容が追加されるデフォルトの位置になります。
![]()
以上でファイルの衝突が解決されたので、開発者 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 を作成します。
- マージされた新しい変更内容は、新しいデルタとして親デルタ 1.6 に追加されます。
- 新しいデルタは、そのワークスペースのオーナーである開発者 B によって所有されます。
- 新しいデルタはデフォルトのデルタになるため、子ワークスペースで以後行われる変更の結果はすべて、このデルタの下に追加されることになります。
![]()
上記のマージ例は、統合ワークスペースと 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
-w
オプションを使用して、ワークスペースを指定できます。-r
オプションには、(filename ファイル内の) SID を指定します。この SID から SMID が求められます。-a
オプションは、filename ファイル内のすべての SID に対する SMID を求める場合に使用します。例
example%freezept smid -r 1.38 module.c
SID 1.38 = SMID "f5b67794 705f0768 a89b1f4 588de104"
SMID から SID への変換
SMID から SID への変換には、
freezept sid
コマンドを使用します。構文は次のとおりです。
freezept sid
[-w
workspace][-m
"SMID"][-a
] filename
-w
オプションを使用して、ワークスペースを指定できます。-m
オプションには、(filename ファイル内の) SMID を指定します。この SMID から、SID が求められます。-a
オプションは、filename ファイル内のすべてのデルタの SID を求める場合に使用します。
注 - SMID にはスペース文字が含まれているため、SMID 全体を引用符で囲む必要があります。
例
example%freezept smid -m "64fdd0df de9d7dd de75812 23da96aa" module.c
SMID "f5b67794 705f0768 a89b1f4 588de104" = SID 1.36
サン・マイクロシステムズ株式会社 Copyright information. All rights reserved. |
ホーム | 目次 | 前ページへ | 次ページへ | 索引 |