Simulinkモデルのバージョン管理システムを構築しよう企画の２回目です。

Simulinkモデルのバージョン管理（１）では、バージョン管理システムの基本について、ものすごくざっくり書きました。

これをベースに、もうちょっと突っ込んだ内容を確認しましょう。

今回のテーマは、「中央型」と「分散型」の違いについてです。

リポジトリをどこに置くのか？

リポジトリとは、バージョン管理システムが、過去のバージョンを保存するための場所でした。では、これをどこに置いたらいいのでしょう？

• 中央型リポジトリ　－　１つのサーバーに置きます
• 分散型リポジトリ　－　複数のサーバーに置きます

２つの考え方があって、「中央型」では、１つのサーバーで集中管理します。一方、「分散型」では、複数のサーバーに分散させます。

といっても訳が分からないですから、もうすこし詳しく見てみましょう。

中央型リポジトリ

CVS、Subversionなどが、これに属します。

中央型では、すべての開発者が１つのサーバーにアクセスします。リポジトリは中央サーバーに置かれ、この１つのリポジトリに対して、みんながそれぞれに保存したり（＝コミット）、取り出したり（＝チェックアウト）します。

中央リポジトリに、全員がアクセスする

とても分かりやすい形ですね。この方式のいいところは、中央でしっかりと管理できるという点です。

たとえば、ecVERSIMを使うと、Simulinkモデルをロックする事ができます。ロックとは、他人がファイルを編集できないようにするという事です。（ただしくは、コミットできなくする）

Simulinkモデル全体だけでなく、とあるSimulinkのサブシステムを１つだけロックする事も出来ます。他のサブシステムはいじってもいいけど、このサブシステムは編集したらダメよ、と。

このアイデアは、とても素晴らしいものです。Simulinkモデルが巨大になってくると、一人でメンテナンスする事が難しくなります。そんな時、なるべく分業を楽にするよう、サブシステム単位でロックを掛けられると、とても便利です。

分散型リポジトリ

Git、Mercurial、Bazaarなどがこれに属します。

分散型リポジトリでは、リポジトリのコピーをあちこちのマシンにばらまきます。それぞれ、好き勝手なリポジトリにアクセスするわけです。

リポジトリのコピーがいっぱいあり、めいめいにアクセスする

そうすると・・・最初は内容がおなじだった各リポジトリが、あっという間に食い違ってきます。ですから、適当な所で同期をとらないといけません。その作業をマージといいます。分散型で開発を行うと、バージョングラフは次のようになります。

枝分かれするバージョン

途中で枝分かれしているのは、別々のリポジトリに分かれて、それぞれ個別にコミットしていたためです。そして、ある程度作業がまとまったところで、マージしてVer1.05という１つのバージョンに戻っています。

分散型では、このようにバラバラのリポジトリに、バラバラにコミットしつつ、たまーにマージして１つのバージョンにまとめる、というような作業を行います。

ちなみに、リポジトリは開発PC内に置いても構いません。開発PCの中に、リポジトリをごっそりコピーしてくる事も普通にできます。

開発PC上のリポジトリ

こうすると、バージョン管理用サーバーとつながっていなくても、開発PC単体でバージョン管理が出来ます。開発PC上でコミットした内容は、あとからサーバー上のバージョン管理システム内リポジトリに反映させる事もできます。

分散型リポジトリのメリット

一般的なソフトウェア開発の場合

一般的なソフトウェア開発において、分散型リポジトリのメリットで良く言われるのが、規模の問題です。１つのサーバーに１０００人とかがアクセスしだすと、収集がつかなくなります。ですから、分散型でもって階層構造をつくることで、１つのサーバーに対するアクセスを減らします。

これは、会社組織と同じです。社長の下に部長がいて、部長の下に課長、係長、主任がいて、という階層構造。この階層構造のおかげで、社長が何万人もの社員に１人１人指示を出さなくても済みます。これと同じ事です。

モデルベース開発の場合

ただし、モデルベース開発において、１つのモデルを数千人とかがアクセスするなんて、まず考えられません。そういう意味では、分散型リポジトリのメリットはありません。

そのかわり、こと自動車業界向けのモデルベース開発においては、別のメリットが出てきます。それは、中央サーバーと必ずしも繋がっていなくてもいい、という点です。

まず、中央サーバーとの通信が何らかのトラブルで断絶してしまった場合。そんな場合でも、お客様は待ってはくれません。分散型であれば、耐障害性はかなり高くなります。

そして何より、モデルは車載で動かす事があります。実際の車両に乗り込み、ラピッドプロトタイピングのためのECUを配置し、その１部あるいは全部のアルゴリズムを、Simulinkモデルで置き換えます。そして実際に試験をしてみて、具合がわるければ、その場でパラメータを書き変えます。

書き換えているうちに、あれ・・・おかしいな・・・さっきはうまくいったのに？という事になった場合。中央型サーバーを車に持ち込むことは非現実的です。ですから、中央型の場合はバージョン管理が効きません。しかし、分散型の場合は開発用のノートPCにリポジトリをまるごと入れておけますので、普通にバージョン管理が出来ます。過去のバージョンと比較して、どこのパラメータがどう書きかえられたのか？という事が簡単に見られます。これは大きなメリットと言えます。

車載でもバージョン管理ができる

まとめ

バージョン管理システムには、中央型と分散型があります。

中央型のメリット： ecVERSIMなどのツールと組み合わせて、きめ細かいモデル管理が出来る

分散型のメリット： 耐障害性が高く、車載でのプロトタイピングなどにも対応できる

中央型は既にecVERSIMという素晴らしいツールがありますので、今回の企画では分散型でもって環境構築をおこなう事にします。

おまけ

開発PC内にリポジトリが置ける事を、あたかも分散型の特権のように書いてしまいました。

しかし、実は中央型であっても、リポジトリを開発PC上に置く事は可能です。たとえばSubversionの場合、リポジトリはサーバー上だけでなく、ローカルフォルダ上に作成する事もできるようになっています。ですから、一人でやる分には、中央型だろうが分散型だろうが、開発PC単体でのバージョン管理は可能です。

ただし問題になるのはマージという作業です。分散型の場合、マージを頻繁に行う事になるため、マージ機能がとてもよく出来ています。一方、中央型ではマージのための機能がプアで、ちょっと難しい事をしようとすると、すぐにエラーになります。

そんなわけで、開発PC単体でのバージョン管理は中央型、分散型ともにできるのですが、その内容を他のリポジトリに簡単に伝搬できるか？という話になると、圧倒的に分散型が有利になります。