-*- Text -*-

	       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
   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.

				 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.
