バージョン管理ファ イルシステムを用いた保守支援ツールの提案
山本 哲男 yy 大阪大学大学院基礎工学研究科〒 560-8531 大阪府豊中市待兼山町 1-3

松下 誠 y井上 克郎 yzz 奈良先端科学技術大学院大学情報科学研究科〒 630-0101 奈良県生駒市高山町 8916-5

Email: ft-yamamt,matusita,inoueg@ics.es.osaka-u.ac.jp

近年のソフトウェアはより大規模化しており，より複雑になってきている．また，ネットワークを用いた分散開発も一般的になってきている．このような開発環境においては，ソフトウェアの開発や保守作業はより困難なものとなってきている．本研究では，ソフトウェアの開発における保守作業を支援するための開発環境 Moraine の提案を行う．Moraine では開発環境自身の変更履歴をバージョン管理ファイ
ルシステムを用いて蓄積し，保守作業の際に利用することが出来る．また，Moraine のデ ータ蓄積部分に関して実装と評価を行い，有効性の確認を行った．
ソフトウェア開発環境，バージョン管理

Software Maintenance Environment with Version Control File SystemyTetsuo YamamotoyMakoto Matsushita

Graduate School of Engineering Science,
Osaka University
1-3 Machikaneyama, Toyonaka,
Osaka 560-8531, Japanyz

Katsuro Inoue

Graduate School of Information Science,
Nara Institute of Science and Technology
8916-5, Takayama, Ikoma,
Nara 630-0101, Japan

Email: ft-yamamt,matusita,inoueg@ics.es.osaka-u.ac.jp

Recently software is large-scale and complex, and is being developed in more distributed way using
a network. In these circumstances, it is more diÆcult to develop and maintain the software. In thispaper, we propose Moraine, an accumulative software development environment for supporting a software maintenance. Moraine records all the changes of les as an evolution history, and trace a history
by speci ed date or query from users' request. We also implement the data accumulative function of
Moraine, and show the performance of le recording.
Software Development Environment, Version Management

1 まえがきクの容量に収まることが期待される．一人のソフ

近年のソフトウェアは大規模化しており，より複雑

トウェア開発者のために数十 G バイト程度のデ ィになってきている．また，開発形態も大人数での開発

スクを用意することが可能になりつつある．また，や分散化の傾向にある．このような環境での，ソフト

圧縮して保存するための CPU 負荷上昇も，4章にウェア開発やソフトウェアの保守作業というのは非常示すように，問題とはならないと考えられる．今に難しいものとなっている．そこで，ソフト ウェアの後，より高性能の CPU を用いることにより，これ

品質や保守性を向上させるための研究が数多く行われらの負荷は相対的に減少すると考えられる．

ている．しかし ながら，現在のソフト ウェアは 新し い ありのままを開発環境を記録したい．
プログラムの開発過程において，過去のバージョンのプロダ クトや，過去に行なった操作をたど ることが出来ると，開発管理や進捗情報の収集に都合が良い．例えば ，プロダクト メトリクスやプロ
セスメトリクスについては，過去から今までのものを容易に収集することができ，プロジェクトの制御に非常に有効である．プロジェクトの途中で，メトリクス収集の方針を変更しても，過去にさかのぼって収集可能である．

環境で実行する際には，その新しい環境に合わせてソフトウェアを変更しなければならない．このソフトウェ
アの保守にかか るコストは非常に大きなものとなっている．これに対する解決策は，新し い環境になったとし てもソフトウェア自身が柔軟に対応するようにソフ
トウェアを開発することである．しかしながら，我々はソフト ウェア自身だけでなくソフト ウェア開発環境自身も環境の進化に対応すべきであると考えている．
将来のソフトウェア開発環境は過去や現在に行った開発環境の拡張であるため，ソフトウェアの進化に対 管理のための諸作業を開発者から隠蔽したい．
バージョン管理システムの導入のために後で述べるような特殊なシステムのインストールやその使用方法など を学ぶのは容易ではない．また，プロ
ジェクト管理のために種々のメトリクス収集ツールの導入やその使用など も大変である．システムの導入や使用のための障害を少なくし ，管理のための諸作業が陽に表れないシステムが開発者にとっては望ましいと思われる．

応するための一つの方法とし てソフト ウェア構成管理やバージョン 管理を行う方法がある．ソフトウェア構
成管理はソフト ウェア開発過程で作成されるプロダ ク
トの識別や制御，状態の把握等をを解決する研究である [3]．ソフトウェア構成管理は開発過程の各段階で行
なわれ る．設計段階では構成要素の決定や確認，コー
デ ィング段階では生成物の変更状態の追跡，リリース段階ではリリースされる生成物の特定を，それぞれ効率良く行なうことを目的とする．しかし ながら，ソフ
トウェアの一貫性を保った構成管理は容易ではない．
多くの場合，RCS[11] や CVS[1] といった既存の構成管理ツールを使用し ている．しかし ，これらの構成管理ツールでは使用するためには，ある特定の方法を正し く用いなければならない．そのため，これらのツールを始めて使う場合には教育や訓練が必要である．また，これらのツールはある特定の構成管理モデルに 依存しており，変更することは容易ではない．
本研究では，ソフトウェアの進化を支援する新しいソフト ウェア開発環境 Moraine を提案する．Moraine
では，バージョン管理を行うファイルシ ステムを用いることによりソフト ウェア開発環境そのものを蓄積することができる．Moraine による開発では，ソフトウェアの開発中に生成し たすべてのファイルに 対する変更が自動的に記録され，いつでも任意の時点のファイルを取り出せることが可能となる．

Moraine の考えの基礎には以下の要因がある．
 デ ィスクや CPU に要する費用が減少している．
4章に示すように，ソフトウェア開発に必要な中間
プロダクトの各バージョンをそのまま，又は圧縮して保存しても，通常，安価で市販されているディス

Moraine は大きく蓄積と参照という二つの機能から構成される．蓄積とは，ソフト ウェアの開発においてファイルに 関するすべての操作を自動的に記録する事である．この蓄積は過去の開発状況を示す．参照とは，
この蓄積されたファイルを参照し 分析することであり，
過去に行われた作業の確認やソフトウェア開発の改善に用いることができる．
以降，2章では，Moraine の基本的な概念について述
べ，3章では，Moraine で必要となる蓄積部分のシステ
ムの実装について示す．そのシステムの評価と考察について 4章で述べ，最後に，本研究のまとめと今後の課
題を 5章で述べる．

2

Moraine の概念
この章では，Moraine の二つの大きな特徴について

述べる．
2.1

蓄積

Moraine は全てのファイルの変更を履歴として記録する．ユーザはファ イルの保存に注意する必要はない．
もし ，ファイルが必要なく消去したいときは，いつでも現在の環境からファイルを消すことが出来る．Moraine

はファイルの消去を監視し ，履歴としてはファ イルを残しておき，ユーザにはファ イルの存在を見せないよ
うに振舞う．ユーザは単にファイルを作成したり更新し ファイルシステムが用いるバージョン管理方式をファイルシステムから独立させることにより，複数の異なる管理方式を使い分けられるようにする．

たり消去したりするだけで，Moraine はファイルの新しVCFS の概要

いバージョンを自動的に作る．そのため，ユーザは新3.2

し いバージョンを作成するための特別なことをする必要は無い．最初に，ツールの使い方など を学ぶ必要は

VCFS では，通常のファイルに対する読み出し（ read
システムコール ），書き込み（ write システムコール ）動無い．ファイルに 対する読み書きなど の一般的な操作

作を直接バージョン 管理作業に対応付ける．そうするは，すべて Moraine によって自動的に記録される．ユー

ことで ，特別な作業を伴わず既存のエディタ等による

ザはファイルについて何も管理する必要はない．結果

ファイルの読み書き作業だけでバージョン管理機能がとし て，通常のファ イルシステム上のファイルの操作利用できる．つまり，実際のファイル操作は，ファイルと Moraine で 管理されているファイルの操作はユーザを操作するユーザプロセスにとっては一般のファイルの視点からすると違いはない．

システム上のファイルを操作するのと同様の操作で可

2.2

参照

Moraine で蓄積されたファイル履歴は，任意の時間やバージョン番号やあるバージョンにユーザによって付能である．
通常ファイルのみバージョンを取り，デ ィレクトリ，
シンボリックリンク，特殊デバイスファイル，ソケット，

けられた名前を指定することで参照することが出来る．

名前付きパイプなどはバージョンを取らない．バージョ

Moraine では自動的に新しいバージョンが出来るので，ンを取るのは ，新規にファイルを作成した場合や，既ユーザにとって意味のあるバージョンに対し ては名前

存のファイルを変更した場合であり，それらを新規バーを付けることが出来る．この名前はバージョンの別名

ジョンの登録作業とし て扱う．また，ファイルを読み出とし て使用可能である．一つ以上のファイルに 同じ 名

す場合，最新のバージョンを読み出すことになる．

前を付けることで ，それらのファ イルを同時に参照することが 出来る．また，ユーザはバージョン間の差分

通常，バージョン記録ファイルはファイルシステム
からは操作を行わないが，ファイル名変更 (rename シやブランチ分けといった操作も用意に行うこととが 出

ステムコール )，削除 (remove システムコール ) について来る．あるバージョンを指定することで，そのバージョ

はバージョン記録ファイルに 対し ても同様の操作を自ンの時点の作業から再開出来る．

Moraine で蓄積されたファ イル履歴はソフト ウェア
メトリクスに利用出来る．ソフト ウェアメトリクスはプロジェクト 管理に使われ，将来のプロジェクトの品
質向上やコスト削減に非常に重要である．

3

Moraine の実装

動的に実行する．また，ファイルの checkin 作業が終わるまで，他のプ ロセスからはそのファイルに対して読み出しのみが行なえる．
3.3

VCFS の設計

VCFS が採用するバージョン管理手法は RCS など で用いられている checkin/checkout モデル [4] を採用した．
これは，バージョン管理を特定の方式に依存するのでは

本章では，Moraine の実装について述べる．Moraine

なく checkin/checkout モデルに基づいたものであればは 2章で述べた大きく二つの部分から構成されるが，今それが使用可能な事を意味する．今回の実装において回はそのうち蓄積部分について実装を行った．今回はは，RCS と VCS という二種類の管理方法を提供する．

蓄積部分について実装を行った．蓄積部分はファイル

VCFS はファイルシステム部分とそれに付随する管システム上のファイル全ての変更記録を保存するシス

理用コマンド 群，バージョン管理デーモン，バージョン

テムであり，以降 VCFS と呼ぶ．

管理サブシステムによって構成される．図 1は各構成要

3.1

VCFS の設計方針

VCFS の設計方針は以下の 3 つである．

素のつながりを表したものである．

VCFS のマウント元のファイルシステムには最新バー
ジョンのファイルとバージョン記録ファイルを保持して ファイルシステムとして実装することで，システムの操作を事前に学ぶ必要がない．

いる．マウント先では最新バージョンのファイルのみ操 ファイルシステムがもつファイル構造が専用の形式に固定されるという欠点を解消するために，既存のファイルシステムを用いた堆積型（ stackable ）ファイルシステムとし て実装する [5]．

というファ イルを作成した場合，/versiondb には，そ作でき，バージョン記録ファイルは見ることが出来ない．
例として，/versiondb を /proj にマウントし，/proj/fooのファイル foo と foo のバージョン記録ファイルが作成される．この際，/versiondb には通常ファイルは ,a をバージョン記録ファイルには ,v をファイル名の最後にのプログラムとして記述することで，バージョン管理シ
User

Kernel

User
Process

User

ステムの移行が容易となる．また，checkin/checkout 用

VCFS

VCD

VFS

Version Management
Sub-System

UNIX File System
(UFS)

VCS

RCS

のツールを，独自の形式で書くことも可能であり，バージョンを記録ファイルに必要な情報を付加したバージョンを付加することが出来る．

Control Commands

DISK
retriveprevious
versionsshow
a delta

3.3.1

ファイルシステム VFS

ファイルシステムとし ての機能をもつ部分であり，

図 1: VCFS の構成

カーネル内のプログラムである．このファイルシステム
に対し てユーザプロセスからファイルの読み出し ，書き込み，ディレクトリの作成等といった一般のファイル

foo/

システムの持つ機能を行うだけで，バージョン管理機

proj

User
foo,a

foo is foo,aversiondb

能が動作する．
ファイル シ ス テ ム には 直 接 物 理 装 置 を 操 作 す る

UFS[10] や LFS[2] といったものや，ネットワークを用い
た NFS といったものがある．VCFS で用いられるファ
イルシ ステムは，既存のファイルシ ステムの上に構築する堆積型ファ イルシステム [5] とし て設計した．

foo,v
Latest堆積型ファイルシステムは，既存のファイルシステ
ム内部の変更は行わない．また，ファイルシ ステムの出力は HDD 等に直接行われず，下層となるファイル
システム上のファイルとして行われる．記憶装置やネッ

図 2: ファイルシステム上のファ イル
付加したファイル名とし て保存される．図 2に示すように /proj/foo は /versiondb/foo,a というファ イルを指すことになる．また，/versiondb/foo,v は /proj の下
では見ることが 出来ない．ユーザは /proj の下のファ
イルのみを操作することになる．
常に最新バージョンのファイルを 1 つのファイルとしてファイルシステム上に置いておく．上の例では，/ver-siondb/foo,a になる．そのため，ファイルの読み書きはそのファ イルに対する読み書きになるため高速に動トワークを処理するコード を書く必要ががなく，移植が容易である．
3.3.2

バージョン管理デーモン VCD

カーネル内のファイルシステムとのやりとりを行う
デ ーモンプログ ラムである．カーネルから依頼され るファイルのバージョン管理を引き受ける．ファイルに対する実際のバージョン 管理は，バージョン管理サブシ
ステムに依頼する．
3.3.3

バージョン管理サブシステム

作する．ファイルを読み出し専用で開いた場合は，従来

実際にバージョンを記録する部分である．バージョのファイルシステム上と同じ 動作をする．それに対し ，

ン管理サブシステムは複数のバージョン管理ツールの書き込みフラグを付けてファイルを開いた場合，読み出集合体である．バージョンを記録を行う場合，いずれ

し，書き込みといった操作は従来と同じであるが，ファかが選択されてそのツールを実行する．

イルに対して閉じる動作（ close システムコール）を行っ

VCFS では，バージョン管理サブシステムとして，既

たとき，そのファイルに対して checkin 動作を行う．こ存のバージョン管理システムを用いており，ファイルシの checkin の動作はカーネル内では動作せす，カーネル

ステムを利用する際に，ど のシステムを利用するかがの外のバージョン 管理デーモンとバージョン管理サブ

選択できる．今回の実装では RCS と VCS の 2 種類のシステムが行う．

バージョン管理サブシステムが利用可能である．

バージョン管理機能をカーネル内に記述しない利点
としては，checkin/checkout の動作をカーネルを変更せプログラムを使ってバージョン管理を行っていた場合，

RCS は各バージョンの差分のみを保存するた
めに広く用いられているツールである．RCS ではバージョンの派生 (木構造) を許す．この派生された枝をブ

RCS で使われている機能をバージョン管理サブシステム

ランチと呼ぶ．

ずに切替えが出来る事があげられる．また，RCS 等のRCSheader

表 2: バージョンヘッダ構造

version header 1

Previous
Version
Offsetversion 1
version header 2Previous
Version
Offset名前
属性

vattr 構造体のサイズ

前オフセット16 バイトLatestVersion
Offsetサイズ

version 2

内容
ファイルの属性を表す vattr 構造体．
前バージョンのヘッダのオ
フセットを表す．

version header 3version 3

3.3.4

管理用コマンド 群

通常のファイル操作では行えない操作をするための
図 3: VCS のファイル形式

表 1: ヘッダ構造
サイズ
内容4 バイト 最新バージョン番号を表す．初期バージ
ョンを 1 とし て以降
2，3，…と続く．
最新オフセット 16 バイト 最新バージョンのヘ
ッダのオフセットを表す．

名前バージョン番号

このサブシステムではバージョン記録ファ イルに対する操作はすべて RCS のコマンド を内部で実行することでバージョンを記録する．

コマンド 群である．
コマンド とし ては以下のものがある．

 任意のバージョンファ イルの取り出し
リビジョン番号や日付など を指定し ，過去のバー
ジョンファ イルを取り出すコマンド である．
 ブランチ作成
RCS など バージョンの派生を許すモデルの場合に，派生を行うコマンドである．VCS など 許さない場
合はこのコマンド を実行しても何も起こらない．
 差分の閲覧バージョン間の差分を取り出すコマンド である．
3.4

VCFS の実装

BSD UNIX[8, 9] 系のオペレ ーティングシステムである FreeBSD 3.0-RELEASE [6] を対象にして実装を行った．

今回作成した単純な機能を持つバージョン管理

実装はすべて C 言語で記述し ，全体で 5000 行程度

システム．各バージョンを圧縮しない形でバージョンになった．それらの内訳は，カーネルへの追加とし てVCS間の差分もとらずにそのまま保存する．バージョンの派生はなく，線型である．RCS と違いバージョン間ののファイルシステムに 4500 行，バージョン管理デーモ
ンに 340 行，その他のバージョン管理サブシステムとの差分情報をとらないことで 高速に動作させることを目

インタフェース等に 300 行である．

的とし ている．

4 評価

VCS のバージョン履歴ファイルのファイル形式を図3にファイルのヘッダを表 1にバージョンヘッダを表 2に示す．checkin 動作は登録するバージョンをバージョン
ヘッダと共にバージョン履歴ファイルに追加していく．
ただし，ヘッダのバージョン番号と最新オフセットは更新しておく．過去のバージョンはヘッダの最新オフセッ
トと各バージョンファイルのバージョンヘッダの前オフ
セット を辿ることで取得可能となる．バージョン記録する際の情報とし て，ファイルの属性をすべて保存するため過去のファ イルを取り出すと，完全に過去の状
態になる．

バージョン管理ファイルシステムの評価を行う．ファイルシ ステムとし ての実用性を考えるうえで有効かどうかを調べる．評価の方法としては，ファイルシステム
として通常用いられる UNIX ファイルシステム (UFS)と堆積型ファイルシステムの一つである NULLFS との比較することで行った．
ファイルシステムの評価とし て以下の 2 種類のテストを行った．

 様々な大きさのファ イルの読み出し ，書き込みのようなファ イルシステムの性能に関するもの．

­ª©ª¥¬££ª¬ª­ª­ª­ª­ª­ª©ª­ª©ª¥¬££ª¬ª«ÀÄ¼ª¼º «ÀÄ¼ª¼º 


























    
¥ÌÄ¹¼ÉwÆ½wÉ¼¸»ÀÅ¾

 











¥ÌÄ¹¼ÉwÆ½wÎÉÀËÀÅ¾







図 4: 1MB の連続読み出し 時間 (Sec)

図 5: 1MB の連続書き込み時間 (Sec) ファイルシステム上に蓄えられるファ イルの大きさに関するもの．

だけの書き込みから 10 回連続までの 10 個の値が各ファ以下で述べるテストはすべて Pentium 166MHz・48M-

B RAM の計算機で評価した．

イルシステムについて存在する．
測定結果を図 5に示す．VCS(SYNC) はバージョン
管理サブシステムとして VCS を用い，完全にバージョンを記録するまでの時間を計測し たものである．RC-

測した．ここで処理時間とは連続した読み出し を行う

S(SYNC) についても同様である．
UFS と比べ，NULLFS は約 10%余計に時間がかかる．
これは読み出しの際の UFS と NULLFS との違いと同じである．読み書き共に 10%程度の時間を余計に必要とする．VCFS と UFS 比べると約 30%の VCFS のほうが遅い．読み込み時には 10%であったが ，書き込みの際プロセスの実行時間である．つまり，プロセスの生成にはバージョンを保存する時間を要するためである．し

から消滅までの時間となる．読み出すファ イルは既にかし ，バージョンの記録が完全に終了する時間は倍以

ファイルシ ステム上に読み出す回数分だけ用意してお上の時間を必要とする．今回の実装ではバージョンの

く．1 回だけの読み出しから 10 回連続までの 10 個の値

記録はカーネル内では 行わず，ユーザプロセスとし てが各ファイルシステムについて存在する．

実行する．そのため，30%程度の時間で書き込みを行う

4.1
4.1.1

性能テスト
読み出しテストファイルの大きさが 1MB の異なるファイルを単一プ
ロセスで繰り返し 連続して読み出す時の処理時間を計

測定結果を図 4に示す．VCFS(RCS) と VCFS(VCS)

プロセスは終了し，バックグランドでバージョン管理サ

はそれぞれバージョン管理サブシステムとし て RCS とブシステムが動作しバージョンの記録を行う．バージョVCS を用いたという事を意味する．
どの回数においても VCFS(RCS) と NULLFS はほとンを記録する機能をカーネル内部から 外し たことで 高

んど 違いが見られない．これによりファイルの読み出し

また，ファ イルの大きさが 32KB にし て書き込みテに関してはファイルシステム内のバージョン管理機能はほとんど 時間がかからないことが分かる．VCFS(RCS)

速性をもつファ イルシステムが実現出来た．
ストを行った．測定結果を図 6に示す．
基本的に上記の 1MB ファ イルの書き込みと同じ 傾や NULLFS は UFS と比べると約 10%余計に時間を要す向が見られるが，ファイルの大きさが小さいときには，るがこれは堆積型ファイルシ ステムとして実装したたバージョン管理サブシステムとして RCS より VCS を用めだと考えられる．

いたほ うが高速に動作する．

4.1.2

書き込みテスト4.1.3

バージョン記録テスト

同様のテストを，書き込みに関し ても行った．ファファイルの更新時の時間について測定を行った．ファイルの大きさを 1MB とし，異なるファイル名で単一プ

イルの大きさが 1MB のファイルを用意し ，各ファイル

ロセスで繰り返し 連続して書き込む時の処理時間の計は RCS で差分が最大なるようにした．更新回数が 0 と測を行った．ここで処理時間とは連続した書き込みをいうのは新規にファイルを作成したという事である．測行うプロセスの実行時間である．書き込むファ イルは定結果を図 7に示す．

ファイルシステム上に存在していないものとする．1 回バージョン管理サブシステムとして RCS を用いた場

«ÀÄ¼ª¼º 





表 3: アプ リケーション作成時間 (Sec)­ª­ª­ª­ª­ª©ª­ª©ª¥¬££ª¬ª

VCFS(VCS)
VCFS(RCS)
NULLFS
UFS



dump
10.96
12.79
11.3
10.9

tar
28.63
33.46
32.01
28.27










   ¥ÌÄ¹¼ÉwÆ½wÎÉÀËÀÅ¾







表 4: データ情報

図 6: 32KB の連続書き込み時間 (Sec)«ÀÄ¼ª¼º ­ª­ª­ª­ª­ª©ª­ª©ª¥¬££ª
¬ª

data1
data2
data3



最終ファ
イル数

総バージ
ョン数

cc 成功回

9339
4067
2543

45
20
18

311
147
247

222
92
110

数

である．




最終ソー
スプログ
ラムの行
数

4.2






¥ÌÄ¹¼ÉwÆ½wÌÇ»¸Ë¼

図 7: バージョンの更新による時間 (Sec)容量テスト

大阪大学基礎工学部情報工学科で行われるコンパイ
ラ作成演習で得られたプログラムの編集履歴デ ータを

VCFS に適用した．ファイルを時刻順にファイルシステ
ム上にコピーしていく．また，更新されたファイルにつ合を除いて更新したときに要する時間は新規にファ イルを作成した時間と同じである．バージョン管理サブシ
ステム VCS は以前のバージョンからの差分は取らずにバージョンの記録を行うため更新回数によらずファ イ
ルの大きさが同じならば ，更新する時間はほぼ 一定である．RCS の場合，前バージョンとの差分をとるため
更新回数が増えると，更新する時間も増加する．
4.1.4

コンパイルテスト

実際のアプリケーションのコンパイルに要する処理時

いてはコンパイル (cc) を実行する．適用し たデ ータを
表 4に示す．
各ファイルシステム上でのソースファイルとコンパイルし た結果のオブジェクトファイルも含む最終的なファイルの総容量を表 5に示す．

UFS 上の容量が元の大きさであり，この大きさと比べるとバージョン管理サブシステムでの容量は大きくなるが，RCS を用いた場合は数倍程度であり，VCS を用いた場合は数十倍まで増加する．採用するバージョン
管理サブシステムによってディスク使用容量が大きく変化する．

間を測定した．測定対象となるアプリケーションとしては FreeBSD に付属の tar と dump のプログラムとし た．
アプ リケーションのソースファ イルは各ファ イルシス
テム上に用意しておき，make の開始から終了までを処

4.3

比較

既存のバージョン管理システムと VCFS についての比較を行う．

理時間とした．測定結果を表 3に示す．

make が行う作業は，異なるソースファイルのコンパ

表 5: デ ィスク使用容量 (KB)

イルの繰り返しである．コンパイルはソースファイルの読み出し，そのソースファイルから生成されたオブジェ
クトファイルの書き込みであり，ファイルシステムに対して読み書きを行う．VCFS は UFS 比べると 20%程度の時間を要する．これは，実用上問題ない程度の時間

data1
data2
data3

UFS
225
117
73

VCFS(RCS)
1388
546
604

VCFS(VCS)
3149
1377
1501

 RCS と VCFSRCS はツール群により構成されたバージョン管理システムであり，VCFS はファイルシステムにバージョン管理機能をもつバージョン管理システムである．しかし ，VCFS では RCS を内部で用いることで RCS が持つ機能をそのまま利用できる．
 3D Filesystem と VCFS
3D Filesystem は UNIX SystemV Release 3 のカーネルを変更することによって，ファ イルシス
テム上に実装されたバージョン管理システムである [7]．3D Filesystem では RCS と同様，ファ イ
ルシステム上のファ イルをプロダ クトとし て扱っている．3D Filesystem，VCFS ともにファイルシ
ステムにバージョン管理機能をもつバージョン管理システムである．ただし ，3D Filesystem では
checkin をユーザが明示的に指示する必要がある．
4.4

考察

性能面およびディスク容量の観点から評価を行った．
今回の評価から以下のようなことが分かる．

 バージョン管理ファイルシステムは一般のファ イ
ルシステムに比べ 20%程度遅いが実用上問題ない．
 バージョン管理サブシステムとして RCS をを用いれば，ディスク使用容量は 10 倍程度であり実用上問題ない．
 高速性を求めるならば VCS を，ディスク使用容量を減らし たいならば RCS をバージョン管理サブシ
ステムに採用すれば良い．

5 まとめ
本研究では，ソフトウェアの進化を支援するソフト
ウェア開発環境に Moraine について述べ，Moraine の基本部分である蓄積部分の実装を行った．Moraine は，ソフトウェアの開発中に生成したすべてのファイルについて自動的にすべての変更を蓄積し ，蓄積したファ イ
ルをいつでも取り出せることが可能となる．
今後，ユーザが 容易に 使用できる保守管理ツールのユーザインタフェースに関する考察を行い，さらにMoraine の実装を進める予定である．また，実運用による Moraine のユーザビリティの評価も必要だと考え
られる．

参考文献
[1] Berliner, B.: CVS II: Parallelizing Software Development, Proceedings of 1990 Winter USENIX
Conference , Washington, D.C. (1990).

[2] Carson, S. and Setia, S.: Optimal Write Batch
Size in Log-Structured File Systems, Computing
Systems , Vol. 7, No. 2, pp. 263{281 (1994).
[3] Conradi, R. and Westfechtel, B.: Version Models for Software Con guration Management, ACM
Computing Surveys , Vol. 30, No. 2, pp. 232{280(1998).
[4] Feiler, P. H.: Con guration Management Models
in Commercial Environments, Technical Report
CMU/SEI-91-TR-7, Software Engineering Institute, Carnegie-Mellon University, Pittsburgh,
Pennsylvania 15213 (1991).
[5] Heidemann, J. and Popek, G.: File-System Development with Stackable Layers, ACM Transactions on Computer Systems , Vol. 12, No. 1, pp.
58{89 (1994).
[6] Hubbard, J. K.: RELEASE NOTES FreeBSD Release 3.0-RELEASE. This document isavailable on the World-Wide Web at the URL\http://www.freebsd.org/releases/3.0R/notes.html".
[7] Korn, D. G. and Krell, E.: A New Dimension
for the Unix File System, Software{Practice andExperience , Vol. 20, No. S1, pp. 19{34 (1990).
[8] Leer, S., McKusick, M., karels, M. and Quarterman, J.: The Design and Implementation of
the 4.3BSD UNIX Operating System , AddisonWesley (1989).
[9] McKusick, M., Bostic, K., karels, M. and Quarterman, J.: The Design and Implementation of
the 4.4BSD UNIX Operating System , AddisonWesley (1996).
[10] McKusick, M., Joy, W., Leer, S. and Fabry, R.:
A Fast File System for UNIX, ACM Transactions
on Computer Systems , Vol. 2, No. 3, pp. 181{197(1984).
[11] Tichy, W. F.: RCS { A System for Version Control, Software{Practice and Experience , Vol. 15,
No. 7, pp. 637{654 (1985).