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

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

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

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

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

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

• ディレクトリ

• 特定のプログラムを構築するために必要なファイル

• 子ワークスペースの全ファイル

ワークスペース間でのプットバックおよびブリングオーバートランザクションの対象となるファイルをグループ化する具体的な方法については、第 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 履歴ファイルをマージし、衝突の存在を開発者に通知