1 Introduction

The Project Revision Control System, PRCS, is the front end to a set of tools that (like CVS) provide a way to deal with sets of files and directories as an entity, preserving coherent versions of the entire set.

Abstractly, PRCS presents you ("the user") with the abstraction of named projects that have multiple (project) versions, each of which is a set of files, arranged into a directory subtree. A project is the collection of all project versions of that project. Each project version contains one distinguished file, called the (project) version descriptor, in the top directory of the subtree, which contains a description of the files included in that particular version. For a project named `P', this file has the name `P.prj' (and so is also called a "`.prj' file"). The operations provided allow you to perform the following actions:

• Create a copy of the directory tree (or a part of it) for a given project version. The files in such a copy are called working files and the root directory for these working files is called a working directory. This process is called checking-out the version (or the working files). You may select a project version to check out by its version number. Modifying the working files has no effect on the project version they came from. See section 6.4 Prcs checkout.
• Create a new project version (and a new project, for the first version) from working files, or from some mix of working files and the files in a another project version. This is called checking-in the version (or the working files). Before any check-in, PRCS checks to see if there have been other modifications to files in this project and warns you of conflicts and discrepancies. See section 6.7 Prcs checkin.
• Search for differences between a project version and working files or between the files in two versions of a project. See section 6.8 Prcs diff.
• Insert changes that occurred between two project versions into working files. This process is called merging because its purpose is to combine changes you have made to a set of working files with changes that others have made in the meantime. It changes only the working files, because in general they will need editing to reconcile places where the two sets of changes conflict. The resulting merged files are marked with distinctive lines indicating places where the two sets of changes that are being combined differ from each other. One typically edits the merged files to reconcile the differences, and then checks in a new version. See section 6.9 Prcs merge.
• Print out information about the versions of a project contained in the repository (see section 6.11 Prcs info).

In addition, you may add and subtract the files contained in a new project version, or move files from one subdirectory to another by editing the working copy of the `.prj' file before checking in the new version. See section 8 Descriptors.

PRCS keeps all checked-in project versions in a projects repository. See section 7 Repository. At any given time, you fix a prevailing repository by setting the environment variable PRCS_REPOSITORY (which defaults to `$HOME/PRCS'), and do not explicitly mention it in any commands. In general, you should modify the projects repository only with the PRCS command or other designated utilities, or the results will be unpredictable.

PRCS uses the approach found in CVS (Concurrent Version System): unlike version control systems such as RCS and SCCS, PRCS locks projects in the repository only while it is actually running (in order to make operations on projects atomic). One simply checks in new versions as desired; the system will warn you if others have made parallel changes to the major version of the project you are working on that may have to be merged with changes you have made.

Where PRCS differs from CVS (and, indeed, other source-code control systems of the author's acquaintance) is in its attempt to provide a particularly simple model to the user. A project is a collection of files, period. Although the current implementation of PRCS actually uses RCS in its implementations, none of the details of RCS are of any consequence to the user.

1.0.1 Acknowledgements

PRCS is somewhat unusual in that I wrote the bulk of this reference manual before implementation started. I am greatly indebted to Josh MacDonald for condensing it from vaporware into real software, and to the Berkeley PATH project and its sponsors for initially paying his way.

Go to the first, previous, next, last section, table of contents.