Many people would like to know what the differences between CVS and
PRCS are. Why should you switch? First, since PRCS does not yet
operate with the client/server model, you should choose CVS if your
needs are distributed. A client/server version of PRCS is planned for
the next major release. Version 1.2 is expected to be the last 1.x
release of PRCS. Second, you should choose CVS if your needs include
running clients on Windows or Macintosh platforms. There are no
current plans to port PRCS to these platforms. With those two items
out of the way, why should you pick PRCS?
See some thoughts from Jim Kingdon, a CVS
PRCS uses atomic operations on project versions, as opposed to
CVS's use of loosely connected file versions. When an operation
completes, all changes that occured are given a new version name.
You may later refer to this version name, instead of refering to
branch names and dates or tags. This alone makes understanding
the version history of your project much easier. Additionally,
it encourages developers to do the right then when the need for
a branch arises, since PRCS branches are easy to create and the
results are easier to understand.
Faster. It uses a repository meta-data cache to speed up most
It's easier to use and lacks the incestuous relation to RCS and all
it's command semantics. None of the PRCS interface issues stem
from the semantics of the underlying RCS commands. As an
implemetation issue, this also leaves the option of changing to a
more efficient storage representation than RCS (This is, in fact,
planned and underway. Old repositories will be upgradable).
- Control over symbolic links and keyword replacement, including
- The flexible 'prcs execute' command allows open-ended extension of
PRCS's features by allowing you to extract selected files and
filenames from the repository and perform shell commands on them.
- Renaming made easy. PRCS allows you to rename, delete, and
reintroduce files. There is no such thing as pruning, because PRCS
records which files are present in which versions, instead of relying
on each RCS file to dictate whether it is present on a branch or at a
certain date. You don't have to worry about unwanted empty
directories or use placeholders to have an empty directory.
Version history is retained across renames, and you can later
compare and merge the contents of the renamed files.
Last modified: Mon Feb 17 06:00:30 PST 1997
Josh MacDonald / firstname.lastname@example.org