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

Slides:



Advertisements
Similar presentations
InstallShieldLecture InstallShield でインストーラを作成する方法 ( 初級編 ) ソニーエンジニアリング 設計 3 部 1 課 齋藤佑輔.
Advertisements

メタモデル記述を用いた成果物間の依存関係追跡手法
シーケンス図の生成のための実行履歴圧縮手法
PROCESS 14:一般情報(2) InstallShieldLecture
最新ファイルの提供を保証する代理FTPサーバの開発
サイボウズ ガルーン バージョン 4.2 機能紹介ガイド 管理権限とアクセス権 第2版
~ 企業内の情報共有のために~ 暗黙知を→形式知へ キッズウェイナレッジのご提案 2003年7月 24日 - 第1版 -
サイボウズ ガルーン バージョン4.0 機能紹介ガイド 管理権限とアクセス権 第1版
IPv6 エニーキャスト ルーティングプロトコル PIA-SM の設計および実装
情報爆発A01支援班 マイサーチエンジン開発環境支援グループ 中村聡史, 大島裕明, 田中克己, 喜連川優
情報伝播によるオブジェクト指向プログラム理解支援の提案
研究の背景 コードクローン ソースコード中に存在する一致または類似したコード片
Webサイト運営 09fi118 橋倉伶奈 09fi131 本間昂 09fi137 三上早紀.
ファイルシステムキャッシュを 考慮した仮想マシン監視機構
既存システムを連携させることによるeラーニング ― MoodleとXoopsのアカウント情報を交換するモジュール ―
研究基盤総合センター 応用加速器部門 木村博美
情報システム構築 -グループ分けとCVSの初期設定-
アプリケーション共有機能 〈参考〉 (図1) (図2)
第7章 データベース管理システム 7.1 データベース管理システムの概要 7.2 データベースの格納方式 7.3 問合せ処理.
バイナリ形式コンポーネントの 収集・解析・検索システムの開発
SS2009 形式手法の適用ワーキング グループの報告
高山建志 五十嵐健夫 テクスチャ合成の新たな応用と展開 k 情報処理 vol.53 No.6 June 2012 pp
川口真司 松下誠 井上克郎 大阪大学大学院情報科学研究科
Java ソフトウェア部品検索システム SPARS-J のための リポジトリ自動更新機能の実現
複数のリポジトリを共有できる 仮想的なバージョン管理システムの提案
SVGを用いた地震データ検索・3D表示アプリケーションの開発
概要 Boxed Economy Simulation Platform(BESP)とその基本構造 BESPの設計・実装におけるポイント!
ソードコードの編集に基づいた コードクローンの分類とその分析システム
関数の変更履歴と呼出し関係に基づいた開発履歴理解支援システムの実現
Javaソースコード蓄積・ 検索システムSPARS-Jの概要
オブジェクト指向プログラムにおける エイリアス解析手法の提案と実現
インラインスクリプトに対するデータフロー 解析を用いた XHTML 文書の構文検証
オープンソース開発の履歴情報を用いたコミュニティ検索支援システム
既存ソフトウェアの変更履歴を利用したソースコード修正支援手法の提案
利用関係に基づく類似度を用いたJavaコンポーネント分類ツールの作成
事務所における情報化の問題点 データが所内で共有されていない、各課ごとに個別に利用されている
クローンセットに対する主要編集者の分析法の提案と調査
実行時情報に基づく OSカーネルのコンフィグ最小化
コードクローン検出ツールを用いた ソースコード分析システムの試作と プログラミング演習への適用
オープンソース開発支援のための ソースコード及びメールの履歴対応表示システム
オープンソース開発支援のための リビジョン情報と電子メールの検索システム
コードクローンに対する一貫性のない変更に起因する欠陥の検出
Webコミュニティ概念を用いた Webマイニングについての研究 A study on Web Mining Based on Web Communities 清水 洋志.
バイトコードを単位とするJavaスライスシステムの試作
ソフトウェア保守のための コードクローン情報検索ツール
コードクローン分類の詳細化に基づく 集約パターンの提案と評価
Virtualizing a Multiprocessor Machine on a Network of Computers
既存ソフトウェアの変更履歴を利用したソースコード修正支援システム
コーディングパターンの あいまい検索の提案と実装
JAVAバイトコードにおける データ依存解析手法の提案と実装
PA PAX パスポート・アドバンテージ パスポート・アドバンテージ PA パスポート・アドバンテージ・エクスプレス PAX +
オブジェクトの協調動作を用いた オブジェクト指向プログラム実行履歴分割手法
仮想マシンと物理マシンを一元管理するための仮想AMT
設計情報の再利用を目的とした UML図の自動推薦ツール
dcNavi:デバッグ支援のための グラフベース推薦システム
ソースコードの差分を用いた関数呼び出し パターンの抽出手法の提案と実装
プログラムの差分記述を 容易に行うための レイヤー機構付きIDEの提案
クローン検出ツールを用いた ソフトウェアシステムの類似度調査
メソッドの同時更新履歴を用いたクラスの機能別分類法
統合開発環境のための プログラミング言語拡張 フレームワーク
強制パススルー機構を用いた VMの安全な帯域外リモート管理
エイリアス関係を考慮した Javaプログラム用静的スライシングツール
プログラムの一時停止時に 将来の実行情報を提供するデバッガ
コードクローン解析に基づく デザインパターン適用候補の検出手法
関数の変更履歴と呼び出し関係に 基づいた開発履歴理解支援システム
オブジェクト指向言語における セキュリティ解析アルゴリズムの提案と実現
ベイジアンネットワークと クラスタリング手法を用いたWeb障害検知システムの開発
GluonJ を用いたビジネスロジックからのデータベースアクセスの分離
強制パススルー機構を用いた VMの安全な帯域外リモート管理
Presentation transcript:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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