Article 952 of gnu.announce: PRCS -- Project Revision Control System This release of PRCS marks a major improvement in the merging and branching capabilities of PRCS. It offers such new features as: -- Merge now uses a more detailed merge history to remove problems associated with merging and such concepts as "vendor branches". Merge histories are now true DAGs, allowing easier, more intuitive, branching and common version selection. -- Selection of merge and diff tools on an individual file basis. Files may now be grouped into groups sharing the same set of attributes. -- Selection of merge default rules on an individual file basis, similar to the selection of merge and diff tools. One could, for example, define a group of binary files which have their merge tool modified to select a copy instead of a merge, or to regenerate the file based on some input. -- Improvements in efficiency, especially to merge. -- Merge detects renamed files, and allows you the option of changing them during the merge process. ABOUT PRCS ========== Announcing version 1.2 of PRCS, the Project Revision Control System. PRCS is the front end to a set of tools that provide a way to deal with sets of files and directories as an entity, preserving coherent versions of the entire set. Its purpose is similar to that of SCCS, RCS, and CVS, but (according to its authors, at least), it is much simpler than any of those systems. The current release, version 1.2, and future releases of PRCS can be found at: ftp://ftp.XCF.Berkeley.EDU/pub/prcs HTML documentation, recent developments, tutorials, and summaries of the differences between PRCS and other version control systems are available online at: http://www.XCF.Berkeley.EDU/~jmacd/prcs.html The web page also contains a number of links to various discussions of PRCS and planned future enhancments, including a client/server architecture expected to be in the next major release of PRCS. PRCS is released under the GNU public license, see the file COPYING for details. Binary releases of PRCS will be made available shortly after this release. COMPARED TO CVS =============== 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? -- 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 its 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. NEWS ==== Besides a number of bug-fixes and minor improvements, a summary of the changes since 1.0 appears below: Summary of changes between 1.1 and 1.2: * Comments are no longer retained inside file entries. Formerly, comments such as (foo ;; THIS (...) ;; AND THIS :symlink ;; AND THIS TOO ) were retained. Now, they are removed and the entire entry will be printed out as (foo (...) :symlink). Unfortunatly, this affects past project files as well. All other comments (except those inside Merge-Parents and New-Merge-Parents) are retained. * New option --plain-format turns off any special formatting of the output. Also affected by environment variable PRCS_PLAIN_FORMAT. * New option --sort=TYPE affects the order in which info outputs version history. It currently accepts two arguments, "version" and "date". Sorting by version is the old, default behaviour which sorts versions by their version number, starting with the major versions ordered by date. Sorting by date is a new behaviour, and sorts all versions by date, regardless of their major version. * The project file syntax is extended. You may now have more than one (Files ...) statement, the result being as if you appended the contents of each. The Files statement may now contain file attributes that apply to all files in the list. These attributes must precede all files in the list, for example: (Files :no-keywords (filea ()) (fileb ()) (Files :symlink (linka ()) (linkb ()) ) Keywords except the ':tag=TAG' keyword may not be repeated. * Merge code completely rewritten. It's more robust, handles all file types, generalized for arbitrary default actions, and delays checking out files until absolutely neccesary (so it's a lot faster). Merge now logs all modifications to the file PROJECT.log. With -l, merge logs all actions (including those which result in "no prompt" or "nothing"). I'm not sure I like the new output formatting, please complain if you don't. * Merge now uses several file attributes to set various parameters. Each rule may have a new action associated with it. Each attribute, `:mergerule1', `:mergerule2', ... `:mergerule14', may have a default action set to one of the five characters 'a', 'd', 'm', 'n', or 'r'. These correspond to the five actions normally presented by merge. Certain restrictions apply. You may only set the default to add for rules with a missing working file and non-missing selected file. You may only set the default to merge or replace for rules with at least the working and selected files present. You may only set the default to delete for rules with the working file absent. For information on each rule and the numbers, see the documentation or the merge tutorial at http://www.xcf.berkeley.edu/~jmacd/merge.html. When the 'm' action is taken merge uses the `:mergetool' attribute, if set, to find a command capable of merging the files. The value of this attribute is interpreted the same as the PRCS_MERGE_COMMAND environment variable, which is used as the value of `:mergetool' in the default group, unless mergetool is already defined there. All attributes are taken from the first file which is not absent among the working file, the selected file, and the common file, in that order. * Diff now uses the `:difftool' attribute, if present to determine a diff tool to use. This defaults to the value of the environment variable PRCS_DIFF_COMMAND. Diff uses the to file's attribute, if present, then the from file's attribute. There are some problems here to sort out, because the project file, for example, has no way of setting it's difftool. * As a seperate part of merge, merge now detects renaming between the common version and selected version and offers to let you rename the file. The name of a file and the merging of it's contents are completely seperate operations, one occuring before the other. * The -F flag was removed. The new behaviour is to match files either by file-family (as with the -F flag) or by name (as without) and resolve ambiguity only when it arises by asking the user what to do. With -f present, the match by file-family is chosen. * Compile-time defaults for the 8 documented environment variables used by PRCS are taken and used as the default when a user runs PRCS without the environment variable set. The autoconf stubs for this are auto-generated as part of the build process. So, PRCS checks first the users's environment, then the builder's environment, and finally uses the documented default. * Slight changes to output of checkin -l. It no longer reports a file has been modified or has a new mode after declaring that the file was added. * Several scripts such as 'prcs-emerge' are included in the distribution but not installed. They include possible external merge and diff tools. * 'prcs execute' now includes the project file in the list of files with the special tag :project-file. Update your uses of this command to use --not=:project-file if this will affect your usage. Directories not explicitely named with :directory are now included with :implicit-directory. * Remove rx-1.5, replace with GNU regex package. It seems to be 64-bit clean, so the Alpha users can be happy. This makes populate and execute once again capable of regular expression matching. For those of you who think, "but my libc has POSIX regex stuff", well, this one seems to be a challenging configure test so I'm going to stick with it the way I have it now. * configure now accepts --disable-mmap to turn of mmap even if it tests okay. * When merge moves a file into the "obsolete" subdirectory, it first finds a unique name by appending ".vN" until it finds a suitable name. * Implement the new command 'prcs depopulate'. This simple command removes the file entries for each names file-or-dir, which as usual defaults to all files (it queries you first, in this case). * The new command 'prcs admin pdelete' which deletes a repository entry. * The new command 'prcs admin prename' which renames a repository entry. * New environment variable, PRCS_DIFF_OPTIONS, is a whitespace- separated list of options to pass to diff during 'prcs diff' and 'prcs merge'. If you need something with whitespace, you'll have to pass it on the command line. Command line options override PRCS_DIFF_OPTIONS. * Fix the `prcs admin access' command to work when run as root. It will let you set users as well as groups when run as root. * Implement new merge algorithm, described in the tutorial at http://www.xcf.berkeley.edu/~jmacd/merge.html. Summary of changes between 1.0 and 1.1: * New project-file entry Project-Keywords introduced. This allows the definition of arbitrary keywords. These keywords are treated just like the 13 builtin keywords and may be included in the special $Format$ keyword directive. * Merge common-version algorithm changed to solve a problem pointed out by Marco Antionotti. When merging a set of working files against a selected version, the common version must be computed. In previous versions of PRCS, this was handled differently: 0.13.x and previous versions: the most recent merged-against version was used or the working version if none exist. 1.0.0 through 1.0.9: the working version was used. In each of these cases, differences arise only after one merge has been completed and no checkin has been done. The algorithm used in 1.0.x failed to handle a very common case well, thus the new algorithm. The very common case is this: version 0.1 is created, user A modifies and checks in version 0.2. User B has 0.1 and merges against 0.2. User A checks in 0.3. User B merges against 0.3. The common version computed by 1.0.x is 0.1, which causes many conflicts caused by re-merging in changes which have already been merged. The new algorithm makes use of an "effective working version", which is computed before the common version is computed. The effective working version is used to compute the common version. If unique, the effective working version is the version picked from the set of previous merge parents and the working version which is closest to the calculated common version. If not unique or the new option -s (--skilled-merge) is supplied, the user is asked to pick a version manually. It is difficult to come up with a situation requiring this intervention. Normally PRCS prevents the same file from being merged twice, so that merges can be interupted or aborted and later resumed. This can cause difficulties for people who really know what they are doing and want to force a merge to occur. The -s option also allows users to remerge files. Checkin with partial merge asks whether to use the merge parent or working version as the effective working version for checkin. Checkin with --skilled-merge asks in either case. * Checkin now reports adds and deletes properly. Behavior of '-l' at checkin changed to only report modified, added, or deleted files. '-L' gives old behavior. Changes reported are relative to the real working version before checkin. * Arguments passed to diff3 changed: arguments were "-ma", and have been changed to "-maE". The result is that only overlapping conflicts are shown, not identical conflicts (where the file in both the selected and working versions contain the same changes). * Complete rewrite of the project-file reading and editing code and the auxiliary data file code (.PROJECT.prcs_aux), it now uses much less memory for large projects. * Project renaming implemented. You may now renaming a project while unpackaging. 'prcs unpackage' accepts an optional argument which is used as the new project name. For example: prcs unpackage P.pkg Q unpackages the project contained in P.pkg (presumably named P) and names it Q. The change affects the history of the project file (it has been called Stalinesque) so that project files from old versions checked out of Q will read as if their name were always Q. A comment is inserted into the project files of old versions to remind the user of the original name of the project when each particular version was checked in. Renaming may only be performed on packages created by prcs-1.1.0 and later, though prcs-1.1.0 and later will recognize the old package format. Old versions of PRCS will not recognize new packages. * Repository directory layout changed to improve performance of large projects. Formerly all files were kept in a flat directory structure, now they are stored in a tree of subdirectories. PRCS has been tested on projects of up to 15000 files. * -jN (--jobs=N) flag implemented to allow multiple processes during checkin. Performance was evaluated for checkout and other commands and not found to be worthwhile. Future vesions may include rewrites to improve concurrency in other commands. Add PRCS_JOB_NUMBER environment variable to set a default for the -j option. * The PRCS_CONFLICT_EDITOR environment variable was added as a means of allowing a user to edit a file immediately after conflicts are created, during the merge. -- -Josh MacDonald