1 Problem and Motivation
*=*=*=*=*=*=*=*=*=*=*=*=*
In today-s world of commercial projects, Version or Revision
Control of source code is considered an essential Quality Management
task. Especially in the Open Source world where contributions are made
by numerous volunteers spread across the world, versioning of source
code is indispensable. Mounting of Version Control Systems (henceforth
called VCS) provide numerous advantages to the lay user. There exist
some solutions for mounting CVS repositories on a local directory.
Most of these solutions however provide only read-only access to the
files. The advantages of a file system mounted versioning repository is
the transparent mechanism for accessing its files. Another advantage of
such a system is that the whole set of files need not be downloaded, but
only those files which are read need to be downloaded from the
repository. This would have excellent implications in conditions
where bandwidth is at a premium.
2 Background and Related Work
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
There have been implementations of a few of the above presented
ideas. Stefan Siegl has created an implementation of the CVS File
System using GNU/Hurd Translators. There have also been some
implementations of mounting CVS repositories as File Systems using the
FUSE libraries, However almost all the implementations are plagued by
one severe constraint -- which is the handling of writes to the
repository. Another shortcoming of the current solutions is that, they
only offer support for the CVS system, and do not provide support for
mounting a generic Version Control System.
3 Approach and Uniqueness
*=*=*=*=*=*=*=*=*=*=*=*=*=
RepoFS is designed to be generic and capable of mounting any kind of
VCS. The logic and code for the respective VCSs will be defined in a
plugin. The project itself will provide a framework for choosing the
right plugin from the available choices and then register the
appropriate call backs. The duty of RepoFS is to:
1. Identify the system which defines the repository being mounted
2. Check if the appropriate plugin is available (Offline or Online)
3. If it is available, then register the appropriate functions from the
plugin for the file system access calls (Refer §3.13Access
Mechanismssubsection.3.1). Read basic repository information, like
the listing of the parent directory, so that the size of the mounted
directory can be determined.
4. If the plugin is not available, attempt to download from the network
and install (since everything is in user space). If the plugin is
still not available report that the File System type is not
supported and exit
Each time a repository is checked out, one would notice that there is
an accompanying directory or file (one or more) along with the checked
out source code, which is not actually part of the files under version
control. This directory holds the revision information of the individual
files and directories of the working copy. When we try to look at an
online repository as an extension of a file system, this directory no
longer holds any relevance. Let us take the case of an SVN (subversion
repository) and work by using the -.svn- virtual directory as example.
The different versions of the files are listed inside the directory
called -versions- and a subdirectory of the same name as the file
itself. i.e. -<mnt-point>/.svn/versions/<file-name>- will list the
different versions of the file based on the version number.
The -status- of a working copy of the code will specify the details
about which files have been modified, etc. This should be accessible by
-<mnt-point>/.svn/status-.
A similar mechanism is used for other commands like diff, log, etc.
The file system mechanisms will be mapped to appropriate VCS mechanisms.
The behavior for independent systems will need to be defined separately.
readdir() should merely list the files in a given directory of the
repository without actually downloading (checking out) the files to the local
machine. read() will actually cause the downloading of the file
to the local machine (unlike open()). The first call of read() will initiate the
checkout of the file. Subsequent calls of read() will merely read it from the
local cache. A repository may be mounted either read only or read write. This
depends on the privileges of the user account. However, if the repository is
mounted by a user with full write permissions, then the write function will
cause changes to be made to the local cache. The changes will not be made
upstream i.e. it will not be committed immediately. The new data of the file is
maintained in cache. The close() call will mirror the local changes on the
upstream repository.
4 Results and Contributions
*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Some of the advantages of such a mounted Version Control Repository
are:
- No need to specify the Version Control System type since it is
determined dynamically based on the URL being mounted
- Ubiquitous access. All applications will be able to access the files
directly from the repository, instead of only the VCS clients
- Implicit Versioning. Each modification of the file will be recorded
in the version control repository
- Pluggable architecture. More modules supporting other VCS can be
added at a later point of time
- Files copied and removed from the mount point is automatically
translated in the version repository.
- Effective alternative to a Versioning File System