CVS Comparisons

• 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 operations.
• 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 custom keywords.
• 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.