The Concurrent Versions System or CVS is an integral part of the CLAY architecture, providing a well managed storage system for projects and documents. The CVS maintains a central repository of data, though it is often used to store and organize source code, it is not limited to this type alone. It is able to store any ASCII file and is able to handle binary files as well, though the cost of doing so is slightly more.

The CVS delivers functionality that allows users to track different versions, know when the last modification was made on the data and by who, merge several different checked out copies into a single master copy, and many other manipulations of data. The basic idea behind the CVS is that users check out a working directory and check in new versions of files. On older versions of the CVS, only one user could check out a particular working directory at a time, but newer versions allow multiple users to check out the same working directory. Likewise, older versions were not able to merge checked in documents, while the newer versions support this functionality.

The ability for developers to have access to the same code deposit and be able to track version numbers and modifications simplify the task of collaborative development on projects. The CVS is a powerful tool when used correctly and allows developers that are physically separated to work together as a team without having to deal with the overhead of managing multiple versions and file assignments.

The CVS can be used over a networked environment and the most efficient way of doing this is by using the CVS-specific protocol. Developers have implemented CVS server/client packages that utilize the CVS-specific protocol and allow easy interface with the Data Repository.

CLAY utilizes the CVS by incorporating a CVS Client connection to a CVS Server within the CLAY Main Server. This connection is passed to the spawned Project Servers. Project Clients that are connected to the Project Servers are able to request an action from the Project Server and, permissions from the Project Client being valid, the Project Server will execute the request on the CVS Client that has the connection to the CVS Server. In this manner all of the Project Clients will seem to have a CVS Client, but in reality only the CLAY Main Server has the Client and the Project Servers are the only ones able to execute commands on it and the only way for these Project Servers to execute commands is through a Project Client with the proper permissions.

To manipulate a CVS, developers use special CVS Clients that connect to special CVS Servers. The CVS Server maintains the repository. The CVS Clients connect to the CVS Server through one of several ways. After connecting, the CVS Client must authenticate itself to the CVS Server. After this is done the CVS Protocol is started. The CVS Server sends responses to the CVS Client only when there is a request from the CVS Client. Since the CVS Server only responds when the CVS Client sends a request, the connection is governed by the CVS Client.

When the CVS Client is finished authenticating, it transmits Valid-responses request to let the CVS Server know what responses the CVS Client supports and Valid-requests request to find what requests the CVS Server supports.

Entries Lines – transmitting RCS data

File Modes – read, write, execute, etc…

Filenames – conventions regarding file names

File Transmissions – how file contents are transmitted

Strings – strings in various requests and responses

Dates – times and dates

Requests – list of requests

Requests that begin with a capital letter do not execute a response from the CVS Server, while all others, with the exception of ‘gzip-file-contents’, do. Unrecognized requests always execute a response from the CVS Server.

Response Pathnames – The "pathname" responses

After a request that requires a response, the CVS Server sends however many of the valid responses are appropriate. The CVS Server should not send data at any other time. All responses end with ‘error’ or ‘ok’, indicating the end of the response.

While searching for information on the CVS and ways of implementing it, we came across this CVS Client Package done completely in JAVA. Information can be found at http://www.jcvs.org/.

This package, developed under a GNU license, incorporates a way to communicate with a CVS Server. By creating an instance of this client on the CLAY Main Server and passing the connection to the Project Severs, we will be able to utilize the CVS.

The JavaDocs for this package can be found at:

http://www.gjt.org/javadoc/com/ice/cvsc/ - client/server protocol

http://www.gjt.org/javadoc/com/ice/jcvsii/ - client application