去年の年末に、NEATさんの忘年会でYさんと雑談していました。どうもSimulinkモデルの場合、バージョン管理システムが使われていないところが多い、との事。うむうむ、いい話を聞きました。

一般的なソフトウェア業界では当然のようにやっている
↓
モデルベース業界では行われていない
↓
ビジネスチャンス到来！？

ちょうどそんな折、コードファインのMさんから「Simulinkのバージョン管理ツール、取り扱い始めます」とのアナウンスがありました。見てみると、なかなか悪くなさそう。基本が押さえられている上に、価格的にも悪くない。ただしトータルシステムではないので、これ買ってもそのままじゃダメです。ある程度システムアップしないと。商売にするとしたら、そこでしょうね。

ブログの企画としてシステムアップしてみる
↓
商売になりそうか考える
↓
儲かりそうなら、本格的に工数を突っ込んで、完成度を上げてみる

こんな感じでいってみます。

バージョン管理とは「過去の版を取っておく」事

原始的な管理方法

私の見た限り、バージョン管理システムなんか使わなくっても、だいたいみなさんバージョン管理はしっかりとしていらっしゃいます。そのやり方は、こうです。

几帳面なAさん（A型）は、モデルを作っています。ちょっと変更しては動かして、ちょっと変更しては動かして・・・よし完成！うむうむ、バージョン１．００は完成です。今日の日付は・・・２０１０年２月２２日。そこで、モデルをフォルダごとコピーします。

• フォルダ「 engine 」 ← 作業対象
• フォルダ「 engine_ver1.00_20100222 」 ← Ver1.00保存版

いっぺん完成と行ったものの、几帳面なAさんは細かいことが気になり始めました。そうして修正しはじめ・・・よし完成！うむうむ、バージョン１．０１は完成です。今日の日付は、まだ２２日か。そこで、モデルをフォルダごとコピーします。

• フォルダ「 engine 」 ← 作業対象
• フォルダ「 engine_ver1.00_20100222 」 ← Ver1.00保存版
• フォルダ「 engine_ver1.01_20100222 」 ← Ver1.01保存版

こうやって、フォルダが際限なく増え続けていきます。フォルダ「 engine 」が最新版で、それ以外のフォルダは過去のバージョン、というわけです。

ここで、おおざっぱなOさん（O型）登場。Oさんは、最新版の 「 engine 」ではなく、過去のバージョンの 「 engine_ver1.00_20100222 」がお気にめした様子。これいーなー、これをベースにしようかなー、と。

おもむろにOさんは、engine_ver1.00_20100222 上で作業を始めます。あれを変えてこれを変えて・・・よっしゃ！Oさんの目的とするモデルは完成！忘れないうちに・・・（上書き）保存！

そこにAさんがやってきて激怒。おいおい！ engine_ver1.00_20100222 は永久保存版なんだってば！なんでそれ修正しちゃってるんだよ！ムッキー！

しかしOさんは動じません。あぁ？そなの？ま、最新版が無事なんだからいーじゃん！

こうして、過去のバージョン ver1.00は、Oさんの上書き保存によって永久に失われました。さようなら、Ver1.00。

バージョン管理システムによる管理

さきほどのAさんは、ちゃーんとバージョン管理していました。でも、Oさんがやってきてブチ壊しに。何が悪かったんでしょう？

几帳面なAさんは、ちゃーんとこまめに版を保存していました。これは、とても良いことです。ただし、保存先を間違えた。いっぺん保存したら、二度と消去できない場所に保存するべきだったんですね。それをやってくれるのが、バージョン管理システムです。

今回は、まずざっくりとバージョン管理システムについて見て行きましょう。

バージョン管理システムとは？

フリーソフトに限定してもいっぱいあります。すごく有名所では、CVS、Subversionなど。あとは、Git、Mercurial、Bazaarなどもあります。それぞれ特色はありますが、基本的には「保存する」「取り出す」「比較する」ためのツールです。

保存する

さきほど几帳面なAさんは、フォルダごとコピーして、ファイルを保存していました。バージョン管理システムを使っても、これと同じ事をできます。

「リポジトリ」に「コミット」する様子

ここで２つほど用語を。

• リポジトリ　－　ファイルやフォルダを丸ごと保存するための場所
• コミット　　－　リポジトリにファイルやフォルダを保存すること

フォルダを丸ごとコピーするかわりに、「リポジトリ」に「コミット」します。そうすると、Aさんの作業はこうかわります。

几帳面なAさん（A型）は、モデルを作っています。ちょっと変更しては動かして、ちょっと変更しては動かして・・・よし完成！うむうむ、バージョン１．００は完成です。よし、「コミット」だっ！これで、フォルダ engine の内容が、バージョン管理システム内の「リポジトリ」に保存されました。

• フォルダ「 engine 」 ← 作業対象
• リポジトリ「 engine の、リビジョン１  」 ← Ver1.00保存版

いっぺん完成と行ったものの、几帳面なAさんは細かいことが気になり始めました。そうして修正しはじめ・・・よし完成！うむうむ、バージョン１．０１は完成です。よし、「コミット」です。

• フォルダ「 engine 」 ← 作業対象
• リポジトリ「 engine の、リビジョン１ 」 ← Ver1.00保存版
• リポジトリ「 engine の、リビジョン２ 」 ← Ver1.01保存版

こうやって、リポジトリにデータが際限なく増え続けていきます。ここでもう１つ用語を。

• リビジョン　－　リポジトリ内に保存されたファイルの、バージョンのようなもの

このように、開発マシンには作業中のファイルしか置きません。過去のバージョンは全てバージョン管理システムに置きます。

バージョン管理システムに置かれた物は基本的に消せません。（たとえ消しても、いつでも元に戻せるようになっている）

取り出す

バージョン管理システムに、過去のバージョンがいっぱいたまってくると、それを取り出したくなる事があります。

リポジトリからチェックアウトする様子

ここで１つ用語を。

• チェックアウト　－　リポジトリからファイルを一式取り出すこと

まぁ、最新版を取りだす事が多いです。しかし最新版のみならず、過去のあらゆるバージョンを取りだす（＝チェックアウト）事ができます。

モデルとかいじっていると、「あー、昔のあのバージョンは、ちゃんと動いてたのになー。おかしいなー」という事があります。そういう場合にも、こまめにコミットさえしていたなら、いつでも好きなバージョンを取り出せます。

比較する

モデルでもCコードでもそうですが、「おかしいな？昔のと今のと挙動がちがうぞ。どこを変えたんだっけ？」と思う時があります。そういう場合も、バージョン管理システムを使えば簡単に比較する事が出来ます。

最新版と、過去のバージョンを比較

何が違うのか？を比較することで、挙動がちがう原因を探る事ができます。

まとめ

バージョン管理システムを使えば、モデルやm-fileなどのファイル一式を、「保存する」「取り出す」「比較する」事ができます。

ただし、実は「比較する」というのはバージョン管理システム単体では不可能です。テキストファイルなり、Simulinkモデルなりを比較するためのツールと組み合わせないといけないのです。

テキストの比較ツールは、WinDiffなどフリーのものがゴロゴロしています。しかしSimulinkモデルの比較ツールは、残念ながらフリーでは手に入りません。

そこで、Simulinkモデルの比較ツールを組み入れた、バージョン管理環境を構築する必要があります。

次回以降、そのための作業を行います。