Moraine: An Accumulative Software Development Environment for
Software EvolutionyTetsuo YamamotoyMakoto Matsushita

Graduate School of Engineering Science,

z

y

y z

Katsuro Inoue

Graduate School of Information Science,

Osaka University

Nara Institute of Science and Technology

1-3 Machikaneyama, Toyonaka,8916-5, Takayama, Ikoma,

Osaka 560-8531, Japan

Nara 630-0101, Japanft-yamamt, matusita, inoueg@ics.es.osaka-u.ac.jp

Abstract

only software itself but also the software development
environment is evolutionable. Since the future software development environments is the successful extension of the past and the present time of them,one of major issues in the support e orts of software
evolution is management of con gurations and versions. The software con gulation management solves
the diÆculties to identify, organize, manage software
products. Managing products is required in eachphase of software development. For example, elements of software component should be clearly identi ed and de ned in a design phase. However, consistent software con gulation management is not easy
work. In many software development organizations,they employ speci c persons who only manage congurations and versions of on-going project.
In many cases, existing con guration management
tools such as RCS[7] and CVS[1] have been used.
However, these version management tools need special care to use properly. For that reason educationand training are essential for beginners. These tools
also rely on speci c proprietary con guration models.
Therefore, it is diÆcult to change the models.
In this paper, we have devised a novel approachfor supporting software evolution. We proposed here
Moraine, which is an accumulative software development environment. Using Moraine, all the lesautomatically are recorded and users can retrieved
speci ed le. The background concepts of Moraineis:Recently software is large-scale and complex, and isbeing developed in more distributed way, with lotsof developers. To solve these circumstances, enabling
the software evolution is now becoming the hot topic
of software engineering; we think it is also importantto evolve not only software itself but also softwaredevelopment environment. In this paper, we propose
Moraine, an accumulative software development environment for software evolution. Moraine records
all the changes of les as an evolution history, andtrace a history by speci ed date or query from users'
request. We also implement a prototype of Moraine,and show the performance of le recording.

1 Introduction
Recently software is large-scale and complex, and isbeing developed in more distributed way, with lots ofdevelopers. In this circumstance, software development and maintenance are very diÆcult. Researches
on improving the quality and maintainability of software have been emerged. However, when a present
software is executed with the new environment, youmust follow it in the change in the environment. The
cost of the maintenance work of the software for thisis very expensive. The ultimate solution is that thesoftware is evolutionable; however, we think that not1 Disc and CPU are becoming very cheap.

meaningful name to a le, because a le automatically recorded. More than one le be retrieved at the We can record all results what we have done.
same time by tagging the same name to les. Users
 We want to decrease management cost as low as can also show a delta between versions and branching is easily established. We can go back to a speci c
possible.
version, and resume our work from that point.
 We do not want speci c models for con guration
Metrics for the evolution is easily obtained by
and versioning.
Moraine. The derived metrics is used for the project
management, and it is very important for the success
Moraine is composed of two features, accumulation of further project.
and reference. All activities to les are recorded automatically by Moraine as an evolution history. Accumulated histories are analysed, and used to improve
the software development.
3 Prototype of Moraine
This paper is organized as follows. In Section2, we
describe about concepts of Moraine. In Section3, we
In this section, we show an experimental implementashow an experimental implementation of a versioning
tion of a versioning le system, which is an accumule system, which is a basic technology needed forlative part and basic technology needed for Moraine.
Moraine. Finally, we conclude this work and present
further works in Section4.
3.1

2 Concept of Moraine

Overview

Moraine consists of two parts which are les recorded
In this section, we explain about two major features part and les referred part. les recorded part is thatof Moraine.
all the les are recorded. les referred part is that therecorded les are viewed in any way. les recordedpart is the core system, which is described in the
2.1
Accumulation
pages that follow. the system is named the version
Moraine records all the les we have created as an control le system(VCFS).
evolution history. We do not need to care the le
VCFS manages the versions of regular les (sympreservation; you can delete it from the current envibolic link, special le, socket, and named-pipe areronment if it is not needed at all. It is easy to createout of our scope). A new version is created i a le isa next version; you can simply edit or create le, andcreated or an existing le is changed. Checking out
old versions will be simply discarded. Thus, we dothe latest version is done with simply reading the le.
not need special preparation for creating a new reVCFS also supports a le locking mechanism. Before
vision. Engineers are not requested to earn how tocheckin is completed, other process can only checking
use it at rst. The typical operations should be auout the le.
tomatically achieved by Moraine. Operations to a
VCFS employs \checkin/checkout model"[2] whichle (read and write) are automatically mapped into
wasproposed by RCS, and VCFS itself does not
activities of version management; engineers do not
have
its own version management mechanism (subconsider what should be done to manage the prodsystem);engineers can import a favorite version manuct versions. Consequently, there are no di erence
agement
sub-system
which is adaptable to the model,
between the operations to usual le system and this
i.e.,
VCFS
can
use
RCS
commands.
le system from a viewpoint of users' processes.
Current prototype of VCFS runs on FreeBSD 3.0RELEASE[3],a BSD UNIX[4, 5] variants. VCFS is
2.2
Reference
written in C and about 5000 lines total; VFS in kernel
Moraine retrieves the history by speci ed time or con- for 4500 lines, VCD for 340 lines, and 300 lines forguration mark given by the user. Users can tag a others.
2

User
User
Process

Kernel

User

foo

VCFS

VCD

VFS

Version Management
Sub-System

UNIX File System
(UFS)

RCS

/

proj

VCS

User
foo is foo,afoo,aControl Commands

DISK
retriveprevious
versions

versiondb

show
a deltafoo,vLatestFigure 1: System overview of VCFS
3.2

System Design

VCFS is composed of le system (VFS), version
control daemon (VCD), version management subsystem, and VFS control commands. Fig. 1 shows
the structure of the VFS components.
The advantage of the separation of version management facility from the kernel is that switching checkin/check-out operations can be easily done. In addition, installing VCFS to a software development organization can be easily performed if RCS is already
employed at the organization. VCFS also allows to
work with yet another check-in/check-out style version management system.

Figure 2: Mapping les between VCFS and actual
le system
process opens a le in write-only or read-write mode,
VCFS hooks close() system call and performs a checkin operation to a le. The check-in operation runs by
the version control daemon and the daemon calls theversion management sub-system which is outside of
the kernel.
3.2.2

Version Control Daemon

VCD is a daemon process which acts as a bridge between the kernel and the version management subsystem. VCD dispatches the request from the kernel
Since VCFS is implemented as a stackable le sys- to the version management sub-system.
tem, all les handled by VCFS are stored to a raw
le system. Each le via VCFS is consists of two actual les; one for the latest version, and another for 3.2.3 Version Management Sub-Systemversion repository (Fig. 2).
The version management sub-system is the actual
Usually VCFS shows the latest version of the le version management part of VCFS. In general, vervia le system. For example, we assume that /ver- sion management sub-system consists of a set of tools.
siondb is mounted to /proj by VCFS and create a le VCFS employs external version management systems/proj/foo. VCFS creates \/versiondb/foo,a" for the as the sub-systems, and we can change the sublatest version of le foo (/proj/foo itself) and \/ver- systems to use. Current prototype of VCFS has two
siondb/foo,v", for the version repository. Note that kinds of version management sub-systems, RCS and/versiondb/foo,v is invisible via VCFS; it is only for VCS.
version management and not for the ordinal operaRCS keeps only a delta of each version and thetion.
latest version. RCS allows version derivation (a tree
VCFS always keeps the latest version of every le structure of version sequence), and a derived version(/versiondb/foo,a in the previous example) for fast is called as a branch. RCS sub-system uses RCS tools
le read/write to the latest version which is modi ed to record versions.
in the most cases of software development. When a
VCS is a simple version management system as theUNIX process opens a le in read-only mode, VCFS one of VMS le system. VCS saves all versions asbehaves as the same as NULL le system[6]. When a is, and does not calculate the delta between versions.
3.2.1

File System

33.2.4«ÀÄ¼ª¼º No version derivation is allowed, however, registeringa new version is faster than the RCS sub-system.
VFS Control Commands

VFS control commands help to control VFS behavior. Following commands are already available. We
are now working on Web-based VCFS tools which
overrides VFS control commands, to support graphical and understandable representation of version history.

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

­ª©ª¥¬££ª
¬ª







 Retrieve previous versions

Users can retrieve any one previous version (notthe latest version) by specifying a version number and/or its created date.

 

Figure 3: Read (1M bytes les)

 Make a branch­ª­ª­ª­ª­ª©ª­ª©ª¥¬££ª¬ª«ÀÄ¼ª¼º Branching is done with control commands if theversion management sub-system has branching
feature.

 Show a delta between versions

Users can check the di erence between versions.

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








Evaluation







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







This section discusses the prototype of VCFS fromviewpoints of the system performance and storage
size. We take up UFS (actually FFS, standard leFigure 4: Write (1M bytes les)system for BSD UNIX) and NULLFS (loop-back lesystem, implemented as a stackable le system) tocompare with our VCFS. All tests are made at our
The time for VCFS(RCS) is almost the same as one
Moraine development testbsd; 166MHz Pentium PC of NULLFS. With regard to le reading, it is underhaving 48MB RAM and FreeBSD 3.0-RELEASE.
stood that it takes almost no extra time as for the version control functions in the le system. VCFS(RCS)
and NULLFS are slower than UFS, since there is an
3.3.1 Performance
implementation overhead of a stackable le system.
At rst, we measured an elapsed time for a UNIXWe also measured an elapsed time to write les,process to read distinct new les of 1M bytes size similar to le reading test described before. Fig.
repeatedly. \An elapsed time" means time between 4 shows the results of writing test. \VCFS(VCS)"
process initiation and process termination; be aware means VCFS using VCS as a version managementthat an elapsed time includes an overhead of typical sub-system. \VCFS(VCS+)" and \VCFS(RCS+)"
UNIX processes (process initialization, etc).
includes a time of synchronization between VCD and
Fig. 3 shows the results of the reading test of sub-system. In general, VCD should not wait the
VCFS, UFS, and NULLFS. \VCFS(RCS)" means termination of sub-system as usual; however we meaVCFS using RCS as the version management sub- sured these for comparison purpose.
system. The vertical axis shows an elapsed time, andNULLFS is about 10% slower than UFS, and it
the horizontal axis shows the number of le reading. is the same of reading test. Writing a le in VCFS
4

Table 1: A sample data
data1
data2
data3

All lines of codes
9339
4067
2543

The number of les
45
20
18

The number of versions
311
147
247

Compilation success number of times
222
92
110

mented and evaluated VCFS which is a basic technology for Moraine.
As a further work, user interface in which users
can retrieve les easily should be implemented. Also,
supporting distributed software development environment and more usability evaluation are required.

Table 2: Total le size (K bytes)
UFS VCFS(RCS) VCFS(VCS)
data1 225
1388
3149
data2 117
546
1377
data3 73604
1501

requires a new version registration which is not reReferences
quired by the reading, so VCFS consumes 30% ormore time compared with UFS. Actual time for a [1] Berliner, B.: CVS II: Parallelizing Software Denew version registration is twice as of UFS, comparvelopment, Proceedings of 1990 Winter USENIX
ing VCFS(RCS+)/VCFS(VCS+) with UFS. ActuConference , Washington, D.C. (1990).
ally, VCD and sub-system work asynchronously so
VCFS is only 30% slower than UFS, and we assume [2] Feiler, P. H.: Con guration Management Models
that it is reasonable.
in Commercial Environments, Technical Report
CMU/SEI-91-TR-7, Software Engineering Institute, Carnegie-Mellon University, Pittsburgh,
3.3.2 File Size
Pennsylvania 15213 (1991).
We applied a sample data taken from a programming
seminar of Osaka University (Table 1), and measures [3] Hubbard, J. K.: RELEASE NOTES FreeBSD
Release 3.0-RELEASE.
This document is
the total le size saved into a lesystem. The test
available on the World-Wide Web at the URL
creates/updates les, and then compile them. Table\http://www.freebsd.org/releases/3.0R/notes.html".
2 shows the result of le size test.
The result of UFS shows an actual size of nal version of products. The result of VCFS shows there are [4] Leer, S., McKusick, M., karels, M. and Quarterman, J.: The Design and Implementation of
more disk spaces to save the whole data; VCFS(RCS)
the 4.3BSD UNIX Operating System , Addisonrequires several times, and VCFS(VCS) requires ten
Wesley (1989).
times as much as of UFS. However, the result of
VCFS(VCS) shows that there are only ten times as [5] McKusick, M., Bostic, K., karels, M. and Quarmuch as the nal version, if we have saved all version
terman, J.: The Design and Implementation ofof les; we think it is reasonable size for supportingthe 4.4BSD UNIX Operating System , Addisonsoftware evolution. Note that the total le size may
Wesley (1996).
vary; it depends on what sub-system is used with
[6] Pendry, J.-S. and McKusick, M.: Union Mounts
VCFS.
in 4.4BSD-Lite, Proceedings of the USENIX 1995
Technical Conference , New Orleans, LA, USA,
4 Conclusion
pp. 25{33 (1995).
In this paper, we proposed \Moraine", an accumula- [7] Tichy, W. F.: RCS { A System for Version Control, Software{Practice and Experience , Vol. 15,
tive software development environment for software
No. 7, pp. 637{654 (1985).
evolution; Moraine records all the les we have created, and shows the history of them. We also imple5