複数のリポジトリを統合できる バージョン管理システムの提案と試作

Presentation on theme: "複数のリポジトリを統合できる バージョン管理システムの提案と試作"— Presentation transcript:

1 複数のリポジトリを統合できる バージョン管理システムの提案と試作
田中 義己 井上研究室 井上研究室の田中義己です． 本日は，「複数のリポジトリを統合できるバージョン管理システムの提案と試作」という タイトルで発表させていただきます． 2001/02/20 修士論文発表会

2 背景 ソフトウェア開発規模の拡大 ソフトウェア品質評価 コンポーネント・モジュール単位 再利用 分散環境 開発組織単位 開発者単位
まず，研究の背景ですが， 近年，ソフトウェアの開発規模が拡大しており，その開発形態も多様化しております． コンポーネントやモジュールといった単位での開発が行われております． そして，それらの再利用します． また，ネットワーク技術の発展に伴い，分散環境やオープンソースでの開発が 広く行われております． その一方，ソフトウェアプロダクトに対する品質の評価が行われる傾向もあります． 評価の対象としては，開発組織単位だけではなく，開発者単位でも行われております． 2001/02/20 修士論文発表会

3 背景 ソフトウェア管理 バージョン管理システムの利用 開発履歴の蓄積・閲覧が可能 バグ発見が容易になる 過去の状態への移行が可能になる
変更の統合が簡単になる ところで，ソフトウェア開発で生成されるプロダクトの管理に， バージョン管理システムが多用されています． このバージョン管理システムでは開発履歴を蓄積し，それらの閲覧が可能となっています． これにより， ・ 2001/02/20 修士論文発表会

4 バージョン管理 プロダクトに対する追加・削除・変更などの作業を履歴として蓄積する 蓄積したデータを開発者に提供する リポジトリ トランク
管理単位：リビジョン プロダクトの 各段階での状態 ・実データ ・属性データ リポジトリ トランク 開発者 1.0 データ操作 開発者 ここで，バージョン管理システム関する簡単な説明，および， 移行の発表で必要となる用語の説明を致します． バージョン管理システムでは， ・ データはリポジトリと呼ばれる格納庫に蓄積されます． このリポジトリの内部で，プロダクトはリビジョンという………………….. (図で順に説明) データ操作 1.0.1 1.1 開発者 1.0.2 1.2 ブランチ リビジョンツリー 2001/02/20 修士論文発表会

5 既存のシステムにおける問題点 開発者単位の履歴蓄積が困難 点在するリポジトリの一元管理が困難 リポジトリ間でのコンポーネント複製
複数の開発者データが混在している 点在するリポジトリの一元管理が困難 異なるリポジトリに存在するコンポーネントは，開発者も別々に管理する必要がある リポジトリ間でのコンポーネント複製 コンポーネントの再利用などで複製と行うと，複製時以降の変更が反映されない 既存のバージョン管理システムにはこういった３つの問題点があります． 順にこれらの説明を行います． 2001/02/20 修士論文発表会

6 問題点１ 開発者単位の履歴蓄積が困難 複数の開発者のデータが 混在している １つのリビジョンデータとして 開発者に依存したデータと
プロダクトデータが一緒に 蓄積されている 開発者 開発者 リポジトリ 問題点の１つ目ですが，開発者の履歴蓄積が困難であるというがあります． 開発者 2001/02/20 修士論文発表会

7 問題点２ 点在するリポジトリの一元管理が困難 異なるリポジトリに 存在するコンポーネ ントを，別々に管理 する必要がある 開発者 リポジトリ
作業領域 作業領域 開発者 2001/02/20 修士論文発表会

8 問題点３ リポジトリ間でのコンポーネント複製 データが冗長になる 複製時以降の複製元 の更新が判らない ⇒反映できない 開発者B 開発者A
(利用者) 開発者A (複製元) 2001/02/20 修士論文発表会

9 解決法 新たなバージョン管理手法 問題点１ 開発者単位の履歴蓄積が困難 問題点２ 点在するリポジトリの 一元管理が困難 問題点３
コンポーネント複製 による問題 解決法１ 開発者単位での 管理を可能にする 解決法２ 複数の作業領域を １つにする 解決法３ 複製を行わずに 参照とする この３つの問題の解決法ですが， 新たなバージョン管理手法 2001/02/20 修士論文発表会

10 バージョン管理手法DiRM/VR 実データと開発者用データを分離して 管理する抽象リポジトリを導入する 開発者単位の履歴蓄積が可能
複数存在するリポジトリの一元管理が可能 コンポーネントの複製が不必要 新たなバージョン管理手法ViRM/VRを提案いたします． このViRM/VRでは，(囲みの中身) この抽象リポジトリは後で説明を行います． この提案手法の新しい部分は，実データと開発者用データを分離して 管理することであります．これにより， ・ 2001/02/20 修士論文発表会

11 抽象リポジトリ ４構成要素 開発者と１対１対応 実データ管理部 属性データ管理部 実データ管理部 インタフェース部 制御部 属性データ管理部
開発者に実データ管理部 と属性データ管理部を統合 した１つのリポジトリを提供 ここで，先程出てきました抽象リポジトリについての説明を行います． ます，アーキテクチャですが，構成要素として， 実データ管理部，属性データ管理部，インタフェース部，制御部の４つが存在します． 実データ管理部以外は，１つの抽象リポジトリには１つしか存在しません． 実データ管理部のみ複数存在する可能性があり，複数の抽象リポジトリで共有されることもあります． 例えば，この図で説明いたしますと，(図を使って説明) また，開発者と抽象リポジトリは１対１対応しております． 実データ管理部では生成されるプロダクトが管理され， 属性データ管理部では開発者に依存したデータが管理されます． このように個別に管理を行うのですが， インターフェース部，および制御部により，開発者に対して１つの管理部として提供することが可能となります． 次に，実データ管理部と属性データ管理部について，もう少し詳しく説明を行います． 属性データ 管理部 実データ 管理部 １つの抽象リポジトリ内に 複数の実データ管理部が 存在しても良い． 抽象リポジトリ 2001/02/20 修士論文発表会

12 実データ管理部 プロダクトデータの管理 開発者の直接データ格納・変更を禁止 １つの抽象リポジトリ内部に複数存在 複数の抽象リポジトリ間で共有
プロダクトデータの信頼性が向上 ⇒制御部を介した間接的アクセス まず，実データ管理部ですが， この部分では開発において生成されるプロダクトデータが管理されます． 先程も述べましたが， ・ また，開発者が実データ管理部に直接アクセスすることを禁止しております．これは， 2001/02/20 修士論文発表会

13 属性データ管理部 開発者依存のデータを管理 実データへのリンクを保持 属性データ管理部の１リ ビジョンは，実データ管理
部の１リビジョンを指す 属性データ 管理部 実データ 管理部 実データ 管理部 次に属性データ管理部ですが， ここでは開発者に依存したデータを管理しております． 各リビジョンの１データとして，実データへのリンク情報を保持しております． 属性データの１リビジョンは実データの１リビジョンに対応することになりますが， (図を指しながら) １つのコンポーネントにおける，２つのリビジョンが， 異なる実データのリビジョンをリンクすることを許します． これによって，より自由に，コンポーネント利用することが可能となるだけでなく． 複数の実データ管理部を統合することも可能となるわけです． この２つのリビジョンは 異なるコンポーネントの リビジョンを指している 2001/02/20 修士論文発表会

14 制御部 実データ管理部へのアクセス データ操作 リビジョン作成(データ格納) データ取得 リビジョン間の差分情報取得 従来方式
実データ管理部のリビジョン利用 リビジョンツリー参照 データ取得 リビジョン間の差分情報取得 リビジョンツリー参照 いままでは，新手法におけるアーキテクチャについての説明をしてきましたが， ここからは，データ操作に関しての説明をいたします． 本手法ではデータ操作として，大きく３つに分類します． その３つとは， ・ です． リビジョン作成については，さらに細かく３種類存在します． 以降，順に説明を行います． 2001/02/20 修士論文発表会

15 リビジョン作成(データ格納) リビジョンツリー参照 実データ管理部内のリビジョンツリー全体もしくはその一部を引用
ツリー構成は参照元と全く同形 複製時以降の複製元に対する変更も容易に反映可能 指定された リビジョンツリー 属性データ 管理部 実データ 管理部 ３つ目にリビジョンツリー参照です． これは，実データ内部に存在するリビジョンツリー全体もしくはその一部を引用します． (図での説明) 後で追加されたリビ ジョンも参照可能 2001/02/20 修士論文発表会

16 システムの試作 新手法に基づいたバージョン管理システム DLCM データ閲覧システム DLCMView 言語 : C++
コード量 : 8500行程度 + ライブラリ(STL) データ閲覧システム DLCMView 言語 : Perl コード量 : 1600行程度 + ライブラリ(jcode.pl) 開発環境，CPU : PentinumⅢ 1GHz × ２ RAM : 1GBytes OS : FreeBSD 4.2-STABLE 2001/02/20 修士論文発表会

17 バージョン管理システム DLCM 実データ管理部 属性データ管理部 インタフェース部 制御部 開発者 DLCM CVSリポジトリの利用
１コンポーネントを１ファイルで管理 インタフェース部 オペレーション解析 制御部 解析結果受け取り 実データ管理部へのアクセス 取り出したデータの閲覧 開発者 DLCM コマンド インタ フェース部 オペレー ション解析 制御部 解析結果 受け取り データ 編集 CVSのイン タフェース まず，バージョン管理システムDLCMですが， 提案した手法に則り， の４部から成ります． ・ 属性データ 用のファイル CVSリポジトリ 属性データ管理部 実データ管理部 2001/02/20 修士論文発表会

18 データ閲覧システム DLCMView コンポーネント一覧 リビジョン一覧 リビジョンデータ閲覧 差分データ閲覧 開発者
属性データ管理部に存在するコンポーネントの一覧 リビジョン一覧 各コンポーネントに存在するリビジョンの一覧 リビジョンデータ閲覧 各リビジョンのデータ表示 差分データ閲覧 ２リビジョン間の差分データ表示 Webブラウザ Webサーバ CGI 次に，データ閲覧システムDLCMViewですが， これは，CGIを利用し，既存のWebブラウザで， リポジトリの内部に格納されているデータの閲覧を可能としております． 閲覧に際しては，４つのモードがあります． ・ DLCMView 属性データ 管理部 実データ 管理部 2001/02/20 修士論文発表会

19 適応実験 開発者単位の履歴を取得する実験 点在するリポジトリを一元管理する実験 コンポーネントの複製せず，参照とする実験
４人の開発者が，コンポーネントに対して行った履歴の取得 点在するリポジトリを一元管理する実験 マルチバイト文字に未対応のライブラリと対応済みのライブラリを利用 コンポーネントの複製せず，参照とする実験 FreeBSDとOpenBSDのコンポーネントを利用 点在するリポジトリを一元管理する実験 2001/02/20 修士論文発表会

20 実験の方法 点在するリポジトリを一元管理する実験 マルチバイト文字に未対応のライブラリから対応済みのライブラリへの移行
strctrl.cpp 実データ 管理部 対応済みの ライブラリ jstrctrl.cpp strctrl.cpp 点在するリポジトリの一元管理する実験として， マルチバイト文字に未対応のライブラリから対応済みのライブラリへ移行する という実験と行いました． (ここから図での説明) 実データ 管理部 属性データ 管理部 2001/02/20 修士論文発表会

21 実験の結果 リビジョンが1.2から1.3に なるときに，実データが strctrl.cppからjstrctrl.cppへ と替わっている
1.4が存在するのは， 一部パスを変更する必要が あったためであり，実際の ソースコードには手を加えて いない マルチバイト文字の処理が 可能となった 2001/02/20 修士論文発表会

22 プロダクトデータと開発者データを分離した
まとめ プロダクトデータと開発者データを分離した バージョン管理システムの提案と試作 開発者単位の履歴蓄積が可能 複数存在するリポジトリの一元管理が可能 コンポーネントの複製が不必要 ⇒適応実験により確認 2001/02/20 修士論文発表会

23 今後の課題 実データ管理部内のリビジョンが繁雑 システムにおける実行時間が長い
リビジョン競合時は，単純に別のリビジョンとして退避し格納する為 ⇒ブランチの利用法を定義 システムにおける実行時間が長い 既存のシステムに比べ，ファイルアクセス回数が多い為 ⇒ファイルアクセスの最適化 今後の課題ですが，実データ管理部内のリビジョンが繁雑になるという問題があります． 実データ管理部は複数の開発者で共有することになるので，その内部でリビジョンの競合が起こる可能性があります． これを回避するため，本手法では単純に別のリビジョンへ退避して格納している為，この問題が生じます． 従って，ブランチの利用法を定義することでこの問題が解決できると考えております． システムの実行時間が長いという問題点もあります． これは既存のシステムにくらべ，ファイルのアクセス回数が多いためであるということが判明しております． 従って，ファイルアクセス部の最適的により，アクセス回数を削減することが解決が可能であると考えております． 以上で，発表を終わります． 2001/02/20 修士論文発表会

24 終 2001/02/20 修士論文発表会

25 バージョン管理システムの利点 バグの発見 パッチを簡単に作成する仕組みの提供 容易に以前のバージョンへ戻すことが可能 変更統合が簡単
グループ作業の簡単化 2001/02/20 修士論文発表会

26 リビジョン作成(データ格納) 従来方式 実データ管理部のリビジョン利用 実データ，属性データ双方のリビジョン作成
既に存在する実データを リンクするリビジョンの作成 属性データ 管理部 属性データ 管理部 実データ 管理部 実データ 管理部 まず，リビジョン作成ですが， １つ目は，従来方式です． この方式では，実データ，属性データ共にリポジトリへ格納を行います． (図での説明) ２つ目は，実データを利用したリビジョン作成です． これは，実データ管理部内に既に存在するリビジョンを利用します． そして，それへのリンク情報を持つリビジョンを作成します． 2001/02/20 修士論文発表会

27 データ取得 リビジョンの内容取得 指定された属性データ 属性データからリンクされている実データ ＋ 開発者 指定された リビジョン
管理部 実データ 管理部 データ操作の２つ目としてデータ取得について説明します． 実データと属性データは別々に蓄積されておりますので， それら共に取り出し，統合して，開発者に提供します． 指定された リビジョン 2001/02/20 修士論文発表会

28 リビジョン間の差分情報取得 実データ内部にある差分情報の利用は不可 互いに異なるコンポーネントのりビジョンである可能性の存在． 差分計算
属性データ 管理部 実データ 管理部 実データ 管理部 ３つ目は，差分情報手法についてですが． 実データ管理部内では，多くの場合，リビジョンを作成した時に， １つ前のリビジョンとの差分データを保持しておりますが， この場合，それらのデータは利用することができません． (図での説明) それは，指定された２つのリビジョンの実データが 異なるコンポーネントのリビジョンである可能性があるからです． 従って，双方のデータを一度取り出して， 差分計算をして，その結果を開発者に提供します． 指定された ２つのリビジョン 2001/02/20 修士論文発表会

29 適応実験１ 開発者を単位とした開発履歴取得 各開発者毎の履歴は 属性データ管理部に存在 システムのログ出力や DLCM Viewerで容易に
閲覧・取得が可能 実データ 管理部 属性データ 管理部 属性データ 管理部 ここまで，試作した２つのシステムを利用しました． 本発表の初めで述べました問題点が解決できることを確認する為に， これらの試作したシステムを利用した３つの適応実験を行いました． １つ目は，各開発者を単位として開発履歴の取得についてです． Main Sub 2001/02/20 修士論文発表会

30 適応実験３ コンポーネントに複製せずに参照する
FreeBSDのopensshコンポーネントをOpenBSDのsshコンポーネントへの参照とした． ５つのファイルに対して変更を行うだけで，実際に実行形式ファイルを作成することができた． 複製ではなく，参照としても問題は生じない 冗長なデータを削減 ３つ目に，コンポーネントの複製問題に関してですが， 2001/02/20 修士論文発表会

31 問題点３ リポジトリ間でのコンポーネント複製 データが冗長になる 複製時以降の更新が 分からない． ⇒反映できない 2001/02/20
修士論文発表会