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). 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