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

親ワークスペースと子ワークスペースにそれぞれ存在する対応ファイル間には、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 履歴ファイルをマージし、衝突の存在を開発者に通知