DRS - Distributed Repository System

1. Description

When working on projects in teams, it is often difficult and time consuming to coordinate simultaneous access to a large number of resources such as source code and documentation. The difficulty level increases with the team size, and with the amount of information that needs to be coordinated. Further complexity is introduced when team members are geographically separated from each other, as is often a reality in today’s modern business environment. These complexities introduce a communications barrier that often leads to degraded productivity in the form of duplicated efforts or clumsy resource sharing. Though shared file systems and mapped network drives provide a basic mechanism for sharing files, they are not a complete solution in that they have limited searching capabilities and limited file locking capabilities. In addition, issues such as file naming convention differences (e.g. MS-DOS’ 8.3 filename limit, or Windows NT’s allowing spaces in filenames) make it difficult for comprehensive file sharing in heterogeneous environments.

A distributed repository system would seem to be an ideal solution to this problem. The DRS is intended to be a scalable distributed system that allows clients to gain access to a generic repository of objects (such as documents and source code). These objects are stored on a number of repository servers that are interconnected. Though the objects are split between these servers, this fact is transparent to users of the system. Java RMI is used to provide open access to the repository for any client platform. The repository also provides a locking service that allows users to claim temporary ownership of a version of an object so that it is not modified by other users.

For a detailed paper addressing Distributed Operating System issues, click here.

Note that this system is not intended to be a production-quality system, and it is not bug-free.  For educational purposes only, I've decided to make the source code publicly available.

2. Disclaimer

THE DISTRIBUTED REPOSITORY SYSTEM JAVA APPLICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MARK ROTH DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO EVENT SHALL MARK ROTH BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MARK ROTH HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

3. Usage Instructions

3.1. System Requirements

To use the Distributed Repository System Application, you must have the following:

4.2. Download and Installation Instructions

To download the system, click on the following link, and uncompress the zip file to any directory.  Then, follow the instructions in the README file: The following information can also be found in the README file:

4.3. Directories

The following directories are found in the distribution:

4.4. To Compile

On Solaris, run compile from the bin directory.  It will build all .class files and store them under src/.../*.class.  On other platforms, examine the contents of the compile script in the bin directory, and execute the equivalent statements.

4.5. Execution

These Execution instructions are for Solaris.  For other platforms, examine the contents of the script files, and build similar script files for your platform.  Note that these scripts are only present as an aid for demonstration in which more than one server is being run on a single machine.  In general, this will not be necessary and only one rmiregistry needs to be set up.

4.5.1. To Execute a Server

First, set your CLASSPATH so it points to the src directory.  Then, run:
    reset <num>
    registry <num> &
    server <num>

Reset will clear out the repository and create a new user called Administrator with administrator access.  The initial password for the administrator will be "password" which can be changed using the user manager utility.

To run successively:
    server <num>

Where <num> is the number of the server being run (start at 1).

To Exit the server, press ^C.  Then, put the registry process in the foreground by typing "fg" and then press ^C to stop it before logging off workstation.

Ports starting at 4000 will be used by default.  The scripts need to be modified to change this.

4.5.2. To Execute a Client

First, set your CLASSPATH so it points to the src directory.  Then, run:
    client <num> <server>

Where <num> is the corresponding server number, and <host> is the name of the machine containing that server.

To exit the client, type exit at the prompt.

4.6. Usage

4.6.1. How to use the Client Software

The client is similar to command-line FTP, and has the following commands, each described below:
 
Command Description
lcd <pathname> Change directory on local filesystem.  Must specify full pathname including root/.
ls List the contents of the current directory.  Directories will appear with a trailing /.
md <dirname> Create a directory from this directory.  The <dirname> cannot specify anything other than a name.  For example "md ../hi" would create a directory literally called "../hi", not a directory called "hi".
cd <dirname> Change current directory.  In this case, <dirname> can either be "/" to change to root, ".." to go up one level, or the name of a directory that exists in the current directory.  Again, something like "cd ../hi" is invalid.
rm <object> Removes the object.  If the object is a directory, all objects in that directory are lost, including subdirectories and all versions of files.  Does not prompt for confirmation.  USE WITH CARE.
mv <object> <path> Move the object with the given name to the given absolte path.  <object> must specify the name of an object in the current directory, and <path> must specify the name of an absolute path, starting with the root /.
ci <name> <ver> <par> Checks in a file to the repository.  A file named <name> must exist in your current working directory.  Specify a string with no spaces to name the version for the <ver> parameter.  The <par> parameter is the name of the parent version to check this file in under.  If this is an initial checkin, the character '/' should be used for <par>.  Otherwise, you must have the parent version locked to check in a new version.  You cannot checkin over an old version.
versions <name> Lists version information and lock information for all versions of the file with the given name.  The <name> parameter must specify the name of a valid file.
co <name> <ver> Checks out the file with the given name into the current working directory.  Overwrites any files in your cwd by the same name.  <name> must specify the name of a valid file, and <ver> must specify a valid version number for that file.
lock <name> <ver> Requests that current user lock the given version of the given file.  <name> must specify the name of a valid file in the current directory, and <ver> must specify a valid version number for that file that has not already been locked by anyone else.
release <name> <ver> Releases a lock for the given version of the given file.  <name> must specify the name of a valid file in the current directory, and <ver> must specify a valid version number for that file that has been locked by someone.
exit Exits and logs off this client from the server.
Administrator Commands: These commands can only be accessed by a user with administrator access (e.g. the Administrator account):
accept <port> Instructs the server to start accepting connections on the given port.
link <host> <port> Links this server with the server on the given host and port.  <host> is the hostname of tha machine running the server.

Notes:

4.6.2. How to use the User Manager

The User Manager is a GUI tool that allows you to add users to a repository user database.  It can only be used from a workstation that has a DISPLAY.  By default, the reset script wipes out the user databse and puts a single user named Administrator in the database.  You can use the User Manager to add other users.

To run the user manager, type:
    usermanager <repository-name>

Where:
    <repository-name> is the name of the repository to modify the User Database for.

Note that changes will not go into effect until the server is restarted.

5. Final Notes

This program was created by Mark Roth, a student at the Rochester Institute of Technology in Rochester, NY.  If you have any questions, comments, suggestions, or bug reports, please do not hesitate to contact me.  My contact information is as follows:

        Mark Roth
        Rochester Institute of Technology
        E-mail: markroth8@yahoo.com


Last Updated: June 12, 1999.