ケース 4

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

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

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

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

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