複数のリポジトリを共有できる 仮想的なバージョン管理システムの提案 田中 義己† 松下 誠† 井上 克郎†‡ †大阪大学 大学院基礎工学研究科 ‡奈良先端科学技術大学院大学 情報科学研究科 大阪大学～～～田中義己と申します 本日は～～～というタイトルで発表させていただきます 2000/11/16 第129回ソフトウェア工学研究会

背景 ソフトウェア規模が増大している ソフトウェア品質改善が行われつつある コンポーネント・モジュール単位 再利用 分散環境 開発組織単位(ISO9000、CMM) 開発者単位 - PSP まず、背景としまして、 最近、開発されるソフトウェアの規模は増大しております。 そのため、 コンポーネントやモジュールといった単位で開発を行なったり、 作成されたコンポーネントなどを再利用します。 また、分散環境での開発も行なわれております。 このように開発の形態も変化しております。 また、一方で、ソフトウェア品質の改善が行われつつあります。 開発組織単位ではISO9000やCMMといった規格に基づいて評価し、それにより改善を行なっています。 最近は開発者単位でも行われております。 2000/11/16 第129回ソフトウェア工学研究会

バージョン管理システム ソフトウェア開発履歴を蓄積する 主なシステム 開発過程の把握が可能 ソフトウェアの品質評価に利用 RCS, CVS ClearCase(Rational社) Visual SourceSafe(Microsoft社) 一方、ソフトウェア管理の方に目を向けると バージョン管理システムを利用することが多くなっております。 これにより、ソフトウェアの開発履歴を蓄積することができます。 蓄積した履歴により、 開発過程の把握ができます。 また、ソフトウェアの品質評価に利用することができます。 現在利用させている主なバージョン管理システムとしまして、 RCS,CVSや、Rational社のClearCase、Microsoft社のVisual Source Safeというものもあります。 2000/11/16 第129回ソフトウェア工学研究会

現状と問題点 ソフトウェアの開発形態は変化している一方 バージョン管理システムは対応できていない 開発者単位の履歴を取得する場合、ソフトウェアの履歴から作成しなければならない 複数のリポジトリから取り出したファイルの一元管理が行なえない しかし、問題点としまして、 ソフトウェアの開発形態は変化しているが、 その一方でバージョン管理システムは対応できていないと考えております。 たとえば、 開発者単位でのソフトウェア品質評価には、 各個人の開発履歴が必要になりますが、ソフトウェアの履歴から作成しなければなりません。 また、複数のリポジトリから取り出したファイルの一元管理を行なえません。 2000/11/16 第129回ソフトウェア工学研究会

問題点の具体例１ 開発者ごとの履歴の取り出し 開発組織単位の 履歴しか蓄積できない ユーザ ユーザ ユーザ リポジトリ 2000/11/16 ここで、問題点の具体例を３つ挙げます。１つ目の具体例です。 現在では、複数の開発者がリポジトリを共同で利用するという形態が主流です。 これにより、開発組織単位での履歴を蓄積することができます。 しかし、各開発者の履歴は、組織の履歴より作成しなければなりません。 リポジトリ 開発組織単位の 履歴しか蓄積できない 2000/11/16 第129回ソフトウェア工学研究会

問題点の具体例２ 類似したコンポーネントへの移行 移行する場合、別のコンポーネントとして扱わなければならない。 ユーザ 日本語非対応のライブラリ ２つ目ですが、現在ソフトウェアの開発にあたり 日本語に対応していないライブラリを利用していたとします。 ところが、急遽、日本語を利用することになり、日本語に対応したライブラリの最新バージョンを使うことになったとします。 しかし、これらを別々のものとして扱わなければなりません。 日本語対応のライブラリ 2000/11/16 第129回ソフトウェア工学研究会

問題点の具体例３ 新たなコンポーネントの導入 更新される度に、複製して採り込まなければならない。 FreeBSD OpenBSDの OpenSSH 更新がある度に 最新のものを 複製している 更新される度に、複製して採り込まなければならない。 ３つ目ですが、FreeBSDにOpenSSHというコンポーネントが存在します。 しかし、このOpenSSHはOpenBSDの方で開発されたものをFreeBSD側に複製しております。 従って、OpenSSHで更新があるたびに、最新版を複製しなければならないという問題があります。 その他 OpenSSH 2000/11/16 第129回ソフトウェア工学研究会

しかし、実データ部分のオーバーヘッドが大きくなる 問題の解決法 開発者単位で 履歴の蓄積を行なう 開発者ごとのソフト ウェア管理を行なう ソフトウェア用のリポジトリとは別に 開発者用のリポジトリを導入する こういった問題点を解決するために、 一般的な解法として、 ～～～という２点があります。 これらを実現するため～～～という方法を採用することが可能です。 しかし、そのまま採用すると～～～となってしまいます。 しかし、実データ部分のオーバーヘッドが大きくなる 2000/11/16 第129回ソフトウェア工学研究会

Distributed Revision Management DiRM/VRの提案 Distributed Revision Management w/ Virtual Repository 実データを格納するリポジトリとは別に 仮想的なリポジトリを導入する 開発者に応じて、必要となるソフトウェアを一元管理することが可能 開発者単位の履歴を容易に得ることができ、開発者毎の品質改善に利用することが可能 再利用の際、既存のソフトウェアコンポーネントを複製ではなく、共有とすることが可能 そこで、 ～～～ということを提案します。 これを実現することにより、 ～～～ となります。 2000/11/16 第129回ソフトウェア工学研究会

DiRM/VRにおける概念要素 仲介レイヤー 物理リポジトリ 抽象リポジトリ ユーザ ユーザ ユーザ ２種類のリポジトリを ユーザ 取りまとめる 物理リポジトリ 実データの管理を行う 抽象リポジトリ 開発者単位での管理 を行う ユーザ ユーザ ユーザ 仲介 仲介 仲介 仲介 抽象 抽象 抽象 抽象 新管理手法における概念要素について説明します。 概念要素には～～～という３つが存在します。 仲介レイヤーというのは～～～ 物理リポジトリは～～～ 次に、この３つの要素について説明します。 抽象リポジトリは～～～ ユーザと仲介レイヤー・抽象リポジトリは１対１の関係にあります。 また、抽象リポジトリは物理リポジトリに格納されている実データを利用します。 物理 物理 物理 2000/11/16 第129回ソフトウェア工学研究会

仲介レイヤー 物理リポジトリと抽象リポジトリを、ユーザ側に１つのリポジトリとして提供する ユーザとのインタフェースを既存のシステムと、ほぼ同様の形式で提供可能となる ユーザがリポジトリに対して行なったオペレーションの解析を行なう 必要に応じて、物理・抽象リポジトリとデータのやり取りをする ３つの概念要素について詳しく説明します。 １つ目は仲介レイヤーです。 この部分の最も重要な役割は～～～です。 これにより～～～となります。 また、 ～～～も行ないます。 2000/11/16 第129回ソフトウェア工学研究会

物理リポジトリ ファイルの実体を管理している 物理リポジトリへのアクセスは仲介レイヤーを通して行なう ファイルの実体だけではなく、それに付随する属性情報やメッセージログなども管理している 物理リポジトリへのアクセスは仲介レイヤーを通して行なう リポジトリ内部データの信頼性を高めるため ２つ目に物理リポジトリです。 このリポジトリでは、ソフトウェアなど実データを管理します。 また、実データに伴う属性やメッセージログ等も管理します この物理リポジトリへのアクセスは～～～ます。 これは～～～のためです。 ただし、実装段階では、 ～～～前提としております。 2000/11/16 第129回ソフトウェア工学研究会

抽象リポジトリ ファイルの実体を持たない仮想リポジトリ ファイルの実体は物理リポジトリから参照する １ファイル内のリビジョンを異なる物理リポジトリから参照してもよい 抽象リポジトリ 最後に抽象リポジトリです。 このリポジトリは実データを管理しない仮想的なリポジトリとなっています。 開発者ごとに存在し、その開発者の履歴を蓄積しています。 実データは物理リポジトリに格納されているものを利用します。 図のように、各リビジョンの実体が異なる物理リポジトリに存在することができます。 物理リポジトリ 物理リポジトリ 2000/11/16 第129回ソフトウェア工学研究会

リビジョンシェアリング 必要なリビジョンのみ共有可能 ユーザAはブランチの部分からは のみ共有している。 他のユーザが行なった更新部分の反映可能 抽象リポジトリ ユーザAはブランチの部分からは のみ共有している。 物理 リポジトリ ユーザA 本手法では、抽象リポジトリ・物理リポジトリという２種類のリポジトリを 利用しているため、リビジョン単位でのソフトウェアの共有を簡単に行なうことができます。 たとえば、右の図で、物理リポジトリに存在するブルーのリビジョンはユーザBに利用されています。 このときに、ユーザAがこのリビジョンを利用する場合に～～～利用することができます。 また、濃い茶色のリビジョンはユーザA・Bが共有しています。 このときに、ユーザAが～～～という更新をした場合、ユーザBはこの変更点を～～～と簡単に取り込むことができます。 ユーザB ユーザAが行なった「 → 」という更新を、ユーザBがを参照するだけで共有可能となる。 抽象リポジトリ 2000/11/16 第129回ソフトウェア工学研究会

DiRM/VRのオペレーション ２種類のリポジトリを扱うため、オペレーションの変更・拡張をする 以下の４つのオペレーションについて説明する Check in Check out Diff Merge このように新たな概念を導入したわけですが、 ２種類のリポジトリを扱うため、オペレーションを変更・拡張が必要となります。 ここでは、バージョン管理システムにおいて、 ファイル操作を行なう、Check in, Check out Diff Mergeという主要な４つのオペレーションについて 説明します。 2000/11/16 第129回ソフトウェア工学研究会

Check in 抽象リポジトリ内に新しくリビジョンを作成するオペレーション Traditional Check in Referential Check in 物理リポジトリのリビジョンを利用したcheck in Extended Check in 複数のリビジョンを同時にcheck in まず最初にCheck inです。 Check inはさらに３つに分かれます。 １つ目に、 ～～～。これは～～～です。 ２つ目に、 ～～～。これは～～～です。 そして、３つ目に、 ～～～。これは～～～です。 2000/11/16 第129回ソフトウェア工学研究会

Traditional Check in ローカルでファイルに変更を加えたものをリポジトリに格納する 物理リポジトリ側で リビジョンの作成に 失敗した場合、全く 変化は起こらない ユーザ 抽象リポジトリ Rev作成 仲介レイヤー CMD解析 物理リポジトリ Rev作成 Traditional Check inは、 ～～～というオペレーションです。 ２種類のリポジトリへアクセスするということ以外は 既存のシステムのオペレーションと変わりありません。 ユーザから仲介レイヤーに～～～となります。 処理 情報更新 ※図中のCMDはコマンド、 Revはリビジョンという意味 以降も同じ 2000/11/16 第129回ソフトウェア工学研究会

Referential Check in 物理リポジトリに存在する１リビジョンを新たに参照する 抽象リポジトリにリビ ジョンが作成されるの ションとなる 抽象 リポジトリ 物理 リポジトリ 次に、Referential Check inです。 これは物理リポジトリに存在するリビジョンを参照する 抽象リポジトリのリビジョンを作成します。 2000/11/16 第129回ソフトウェア工学研究会

Extended Check in 物理リポジトリから派生関係にある複数のリビジョンを参照する RT (revision tree) Check in １つのリビジョンをルートとするリビジョンツリー全体を参照 SQ (sequential) Check in 互いに派生関係にある２つのリビジョン間に存在するリビジョンを参照 そして、Extended Check inです。 これは、物理リポジトリに存在する派生関係にある複数のリビジョンを参照します。 ２つ存在に、１つは、Revision Tree Check inで、これは～～～です。 もう１つは、Sequential Check inで、これは～～～です。 ただし、指定する２つのリビジョンは～～～という関係になければなりません。 2000/11/16 第129回ソフトウェア工学研究会

Extended Check in RT Check in SQ Check in 指定不可 指定可能 抽象 抽象 リポジトリ リポジトリ 物理 リポジトリ 物理 リポジトリ 少し複雑なので、この２つのオペレーションを図を利用して説明します。 まず、 ～～～ですが、物理リポジトリの、この灰色をルートとするリビジョンツリーの部分、 赤の破線で囲まれた部分になりますが、この部分を利用したいとします。 この場合、このオペレーションにより、このように、取り込むことができます。 そして、 ～～～ですが、この２つのリビジョンを指定したとします。 これらは、互いに派生関係にあるので指定することができます。 そして、このオペレーションにより、指定した２つのリビジョンを含む、 この３つのリビジョンを取り込むことができます。 しかし、この２つ黄色のリビジョンは互いに派生関係にはないので指定することは出来ません。 ：指定したリビジョン 2000/11/16 第129回ソフトウェア工学研究会

Check out １リビジョン分のデータを取り出すオペレーション 抽象リポジトリ内部で 各リビジョンの情報と して、実データの所在 を持っている。それを 基に物理リポジトリか らデータを取り出す。 ユーザ 抽象リポジトリ 所在確認 仲介レイヤー CMD解析 パス情報 物理リポジトリ ２つのオペレーションのCheck outです。 ２種類のリポジトリへアクセスするということ以外は 既存のシステムのオペレーションと変わりありません。 ユーザは仲介レイヤーに～～～となります。 処理 取り出し 2000/11/16 第129回ソフトウェア工学研究会

Diff ２つのリビジョン間の差分情報を得るためのオペレーション それぞれのリビジョンを取り出してから計算する 物理リポジトリが異なる場合でも計算可能 ユーザ 仲介レイヤー CMD解析 差分計算 差分計算 抽象 リポジトリ 物理 リポジトリ 物理 リポジトリ ３つ目のDiffオペレーションです。 ２つのリビジョン間の差分情報を得るために利用します。 指定した２つのリビジョンの実体を取り出し、仲介レイヤーで差分情報の計算を行います。 そして、その計算結果をユーザに返します。 物理リポジトリに既存のシステムを利用した場合、 物理リポジトリ自体が備えているDiffオペレーションが存在するのですが、 このように、対象となるファイルを一度取り出してから差分情報を計算するのには理由があります。 それは、指定した２つのリビジョンが同じ物理リポジトリ内に存在する場合と、 しない場合があるからです。 従って、対象となる２つのファイルを取り出して差分計算をすることにより、 どちらの場合にも対応しております。 2000/11/16 第129回ソフトウェア工学研究会

Merge ２つのリビジョンを統合するオペレーション 差分情報の計算はDiffと同じ 差分情報が当てはまらない場合は、何の変化も無し ユーザ 仲介レイヤー ２つのリビジョンを統合するオペレーション 差分情報の計算はDiffと同じ 差分情報が当てはまらない場合は、何の変化も無し CMD解析 差分計算 差分計算 抽象 リポジトリ 物理 リポジトリ 物理 リポジトリ 最後にMergeオペレーションです。 このオペレーションは２つのリビジョンを統合します。 統合するためには、２つのリビジョン間の差分情報が必要になりますが、 この差順情報は先程のDiffオペレーションと同じように行ないます。 ２つの～～～行ないます。 そして、その計算結果を基に２つのリビジョンを統合した、リビジョンを作成します。 2000/11/16 第129回ソフトウェア工学研究会

具体的な利用例１ 開発者ごとの履歴の取り出し ユーザ 抽象リポジトリ ユーザ ユーザ 抽象リポジトリ 抽象リポジトリ 物理リポジトリ 今までに述べたのが、新管理手法になります。 この手法を用いて、初めに述べた３つの具体的な問題の解決法を説明します。 まず、１つ目の開発者ごとの履歴の取り出しについてです。 新手法では抽象リポジトリが、開発者ごとに存在し、その部分に履歴が蓄積されるので これをそのまま利用することができます。 物理リポジトリ 2000/11/16 第129回ソフトウェア工学研究会

具体的な利用例２ 類似したコンポーネントへの移行 開発者 日本語非対応のライブラリ 日本語対応のライブラリ 2000/11/16 開発者　　　　　　　　　　　　　　　 日本語非対応のライブラリ ２つ目に類似したコンポーネントへの移行ですが、 異なる物理リポジトリからでも参照することができるので、 日本語対応のライブラリにおける最新のリビジョンを、このように取り込むことができます。 これにより、この２つ類似したライブラリを同一のコンポーネントとして利用することが 可能となります。 日本語対応のライブラリ 2000/11/16 第129回ソフトウェア工学研究会

具体的な利用例３ 新たなコンポーネントの導入 既存の コンポーネント FreeBSD OpenBSDの OpenSSH 2000/11/16 ３つ目に新たなコンポーネントの導入です。 この場合、FreeBSDという抽象リポジトリを作成し、 この部分から、OpenSSH以外のコンポーネントを既存のFreeBSDのコンポーネントから参照し、 OpenSSHはOpenBSDから参照するようにしておきます。 これにより、新たに更新が行なわれるたびに複製する必要がなく、履歴も残すことができます。 2000/11/16 第129回ソフトウェア工学研究会

システムの構築 DiRM/VRに基づいて、現在、実際にシステムを構築している 開発者ごとに履歴を蓄積することが可能 開発者単位で必要なソフトウェアコンポーネントを一元管理することが可能 現在、今までに述べた手法DiRM/VRに基づいて、システムを構築しております。 このシステムでは、～～～を提供しております。 2000/11/16 第129回ソフトウェア工学研究会

システムの構成 仲介システム 物理リポジトリ 抽象リポジトリ 主にこの部分を構築する 既存のシステムであるCVSを利用 システムの仕様に則ったファイルの集合 そのシステム構成ですが、 大きくは、仲介システム、物理リポジトリ、抽象リポジトリからなります。 仲介システムは～～～。 物理リポジトリは～～～。 抽象リポジトリは～～～。 2000/11/16 第129回ソフトウェア工学研究会

システムのデータ流れ リポジトリ用 ファイル集合 抽象 リポジトリ 抽象リポジトリ アクセス部 コマンド 解析部 ユーザ 仲介システム 指示 ユーザ オペレー ション コマンド 解析部 情報・データ 情報・データ 指示 情報・ ファイル 物理リポジトリ データ 解析部 情報・データ インタフェース 本システムにおけるデータの流れを、図を用いて説明します。 ユーザは～～～。 物理 リポジトリ アクセス部 CVS リポジトリ アクセス 2000/11/16 第129回ソフトウェア工学研究会

まとめ 仮想的リポジトリを利用した、開発者指向のバージョン管理システムを提案した 物理・抽象リポジトリおよび、仲介レイヤー といった概念を導入 開発者単位で、実際の開発に沿った形で、 ソフトウェア管理や履歴の蓄積が可能 個人のソフトウェアプロセス評価に利用可能 まとめです。 仮想的なリポジトリを利用した、開発者指向のバージョン管理システムを提案しました。 本手法では、物理・抽象リポジトリ、および仲介レイヤーといった概念を導入しました。 これにより、開発者単位で、実際の開発にそった形でソフトウェアの管理や、 履歴の蓄積をすることができます。 また、蓄積された履歴を利用することにより、開発者個人の品質評価に利用することができます。 2000/11/16 第129回ソフトウェア工学研究会

今後の課題 システム評価 実際の開発環境へ適用 パフォーマンスの測定 オペレーション実行時間の測定 →既存のシステムと比較する オーバーヘッドの計測 抽象リポジトリとして利用したファイルサイズの計測 →ファイル全体から見た割合を計測 実際の開発環境へ適用 開発者ごとに蓄積した履歴の有効性の測定 開発者にとっての利用し易さの測定 今後の課題ですが、 システムの評価を考えております。 １つ目にパフォーマンスの測定を考えております。 各オペレーションの実行時間を測定し既存のシステムのものと比較を行います。 ２つ目におーばーヘッドの計測を考えております。 本手法では抽象リポジトリを新たに導入しているために、それに必要となるディスク領域が、既存のシステムに比べて 多くなります。ファイル全体におけるこれらのファイルの割合をの計測を行います。 また、実際の開発環境への適応も考えております。 これにより、開発者ごとに蓄積した履歴の有効性の測定や開発者にとっての利用し易さの測定を行なおうと思っております。 2000/11/16 第129回ソフトウェア工学研究会

終 2000/11/16 第129回ソフトウェア工学研究会

システムの試作(物理リポジトリ) 物理リポジトリしては、既存のシステムであるCVSを利用する 特別に『操作可能権限』を得ることで、物理リポジトリへの直接アクセスが可能となる。 2000/11/16 第129回ソフトウェア工学研究会

システムの試作(抽象リポジトリ) 各リビジョンの属性情報が書かれたファイルの集合 抽象リポジトリの中で、複数のプロジェクトを管理可能 １つのプロジェクトに、複数のファイルが存在する 2000/11/16 第129回ソフトウェア工学研究会

システムの試作(仲介システム) コマンド解析部 物理リポジトリアクセス部 抽象リポジトリアクセス部 データ処理部 ユーザからのオペレーションを解析し、各リポジトリへ命令を出す 物理リポジトリアクセス部 CVSインタフェースで適当なコマンドを実行する 抽象リポジトリアクセス部 属性情報が蓄積されているファイルに直接アクセスして、情報を取得する データ処理部 物理・抽象リポジトリから得た情報を処理する 2000/11/16 第129回ソフトウェア工学研究会