Simulinkモデルのバージョン管理（４）からの続きです。今回はテキストファイルのバージョン管理を行います。

分散型バージョン管理システムとして、MercurialベースのKiln（FogCreek社）を採用しました。

やることは、次の５つです。

• リポジトリを作る
• リポジトリにファイルを保存する
• コードレビューする
• バージョンを戻したり、差分を見たりする
• 複数の人が別々に行った変更を、統合する

前回までに上４つをやりましたので、今回は最後の１つをやります。

複数の人が別々に行った変更を、統合する

＆（中央サーバー、および開発PCを使用する）

中央サーバーは、複数のエンジニアが共有して使用します。当然、エンジニアが別々に独自の変更を加えることもありえます。

そういった場合には、３点マージとよばれる作業を行います。３点とは、

• ベースとなったバージョン
• 開発者Aが変更したバージョン
• 開発者Bが変更したバージョン

です。

これら３つを見比べながら、「マージしたバージョン」を作り上げます。

単純なシナリオで、これをやってみることにしましょう。

まず、開発者Aがいくつかのコミットを行い、それを中央サーバーにPushしたとしましょう。すると、こんな感じになります。

中央サーバーに、開発者Aの変更をPushした

ここで、開発者Bが加えた変更をPushしようとすると・・・エラーが起きます。

開発者Bから中央サーバーへのPushは失敗する

なぜなら、開発者Aが既に別の変更を加えているからです。こういう場合に、マージという作業を行います。

まず、TortoiseHG ＞ Synchronizeにて、Pullを実施します。

Pullを実施する

すると、枝分かれしたバージョンの情報が開発者Bのマシンに取り込まれます。これをTortoiseHGのHG Repository Browserで見てみると、こんな感じになります。

枝分かれしたバージョン

この枝分かれしたバージョンを、再び１つにマージしましょう。ここで３点マージです。HG Repository Browser上で、tip を選択し、Merge with… を選択します。

tip で Merge with

すると、次のように３つのバージョンが表示されます。

ベースとなったバージョン、開発者Bのバージョン、開発者Aのバージョン

下半分のエディタ部分でマージを実施しましょう。その結果を保存し、続く画面でCommitをクリックすると・・・マージ完了です。HG Repository Browserは次のような感じになります。

マージされた２つのバージョン

この状態で中央サーバーにPushすると、成功します。Kilnの画面もこんな感じになります。

Kilnにも変更が反映された

まとめ

今回は、別々の人が行った変更を統合しました。やる事は、

• いったんPullする
• Mergeする
• Commitする
• Pushする

たったこれだけの事です。

さて、ここまではテキストベースのお話です。次回いよいよSimulinkモデルのバージョン管理を行います。