			Release Notes for Perforce
	    The FAST Software Configuration Management System

Introduction

	This document lists all user-visible changes to Perforce.
	Beginning with Release #1525, a release is identified by two
	numbers:  its major functionality release number (e.g. 1525),
	which corresponds to number on the cover of the user manual;
	and its minor bugfix release number, which indicates any fixes
	made since the major release.  For example, #1525-1547 is a
	bugfix release of #1525 that includes all changes up to #1547.

	Both "p4" and "p4d" will report their version information by
	passing the "-V" flag.  Additionally, "p4" can report the server's
	information with the "p4 info" command.


Changes Since #2020

	#2254
	    Getting a symlink file on NT would cause the p4 client program
	    to crash.  Now it behaves as advertised: symlinks are treated
	    as (small) text files on NT.  (Bug #167).

	#2246
	    When integrating a symlink into a text file, the 'p4 resolve'
	    command would stop with a "readlink" error.  Now it provides
	    the user with the binary choice of taking either the contents
	    of the symlink or the contents of the text file.  (Bug #166).

	#2234
	    If an unknown hostname was given in P4PORT or on the p4
	    command line with -p, the p4 client command would crash.
	    This has been corrected.  (Bug #165).

	#2165
	    Perforce servers now support Apple Macintosh clients.

	#2159
	    Spaces are now permitted in file names and the client's root
	    directory, with two provisions: file names cannot begin or
	    end with spaces; client or branch mappings connot contain
	    spaces and so cannot explicitly match files that have spaces
	    in them.  Use wildcards to match the spaces.

	#2133
	    Depot file names that had double /'s in them can be confusing
	    to Perforce.  Most notably, the server wasn't able to create
	    a directory in the archive for such files.  Now the server
	    and client can properly create directories with double (or
	    more) /'s in them.  (Bug #140).  

	    It still can be confusing for users to have depot files with
	    multiple /'s in them, and this is best avoided.  The most
	    common cause of extra /'s in depot file name is a missing
	    / in the client file name of a client mapping, e.g.

			//depot/main/... //client/dir...

	    Note the missing / after 'dir'.

	#2130
	    If a client mapping had more than one line and then a
	    label was referenced through that mapping (via 'p4 get',
	    'p4 files', etc), then the server would act as if the
	    client mapping had only one entry.  If this was on a
	    'p4 get', it would then try to delete the files mapped
	    through the second and subsequent lines.  This has been
	    corrected.  (Bug #160).

	#2129
	    Spaces are now allowed in the user name ($USER), but are
	    translated to _.  Previously, they weren't permitted and
	    often the resulting error would crash the server. (Bug #142).

	#2125
	    Against the NT server, a 'p4 where' followed by any command
	    without arguments would pretend "..." was passed as an argument.
	    This has been corrected.  (Bug #153).

	#2110
	    If you tried to delete a user with opened files, 'p4 user -d'
	    would emit errors about table locking problems.  This has been
	    corrected, so that it simply reports that the user has opened
	    files and thus can't be deleted.  (Bug #158).

	#2091
	    So as to support clients under automounted directories (whose
	    absolute path may change from machine to machine), the "p4"
	    client program now uses the value of $PWD in preference to
	    the value returned by getcwd().  (Bug #115).

	#2078
	    File name patterns with multiple ...'s are not supported by
	    Perforce.  Previously, however, it would still allow them to
	    be used on the command line (and would give undesirable
	    results).  Now file name patterns with multiple ...'s are
	    explicitly disallowed.  (Bug #143).

Release #2020, September 1996.
Changes between #1525 and #2020.

Compatibility

	Release #2020 is largely compatible with previous releases, with
	the following provisions:

	1.      Once you run a #2020 server against a Perforce depot,
		it should not be downgraded to a previous server, because
		various new datatypes will not be recognized by the old
		servers.  These datatypes are in support of new client
		file types and change review.

	2.      You can mix #2020 and earlier (#1525, #1223, #827)
		clients and servers, but some functionality new to #2020
		requires upgraded clients and/or servers.

	3.	Servers are licensed differently in #2020.  See below.

Major New Functionality

	P3 renamed P4 - #2011

	    To be more in line with the new product name (Perforce) all
	    references to P3 have been changed to P4.  The client
	    command is now p4; the server command is now p4d.  The
	    client name is overridden with the environment variable
	    $P4CLIENT and the server root directory is set with $P4ROOT.
	    $P4PORT sets the server listen port, and the default port is
	    now "perforce:1666" (_not_ "p4:1666").

	    For the time being, $P3CLIENT, $P3ROOT, $P3PORT, and the
	    default port "p3:1666" will also be recognized.  This
	    compatibility will disapppear in a future release.

	    All references to P3 in this document have been retroactively
	    changed to P4 or Perforce, as appropriate.

	CHANGE REVIEW - #1949 

	    Perforce now supports change review, where users can receive
	    automated email about changes submitted to the Perforce
	    depot.  There are four separate components: The client
	    commands "p4 user", "p4 review" and "p4 reviews" and the
	    daemon program "perfreview.perl".

	    The user interface is through the "p4 user" command: this
	    command allows users to edit their user specification, which
	    includes a list of files to review.  The list can include
	    the usual Perforce wildcards (*, and ...).

	    The automation is provided by a change review daemon script,
	    "perfreview.perl".  This script, available in stock form
	    from the Perforce Web pages (www.perforce.com) can be
	    customized for local preferences.  The review daemon uses
	    the "p4 review" command to produce a list of changes not yet
	    reviewed and uses the "p4 reviews" command to determine
	    which users are subscribed to the files affected by each
	    change.  The review daemon sends email containing a short
	    change description (from "p4 describe -s") to the reviewers
	    of the change.

	    See the "Change Review" chapter in the Users Manual for more
	    information.

	DISCONNECTED CLIENT SUPPORT - #1935, #1737, #1997, #2024

	    To support Perforce client workspaces that must disconnect
	    from the network (and thus from the Perforce server), a few
	    enhancements have been made to the "p4 diff" command.  First,
	    through use of file fingerprinting the command operation is
	    now much faster, particularly over slow networks.  Second,
	    a new flag "p4 diff -s" reduces the output to simply the
	    names of files matching certain criteria:

		diff -sa        Opened files that are different than
				the revision in the depot, or missing.

		diff -sd        Unopened files that are missing on the
				client.

		diff -se        Unopened files that are different than
				the revision in the depot.

		diff -sr        Opened files that are the same as the
				revision in the depot.

	    The enhanced "p4 diff" command makes it possible for a user
	    to get files from the depot, disconnect from the network,
	    edit or delete files directly without using the "p4 edit"
	    command, and then have Perforce figure out what has changed.
	    (The user must manually give the files write permission.)

	    To open files that have changed or been deleted, use:
		
		p4 edit `p4 diff -se`
		p4 delete `p4 diff -sd`

	    To revert files that haven't changed, use:

		p4 revert `p4 diff -sr`

	USER TRACKING - #1911

	    Users of Perforce are now tracked.  By running any client
	    command (with the exceptions of "help", "info", "user", and
	    "users") the user will be added to the list of known users,
	    if not already present, and the user's access time will be
	    updated (to within one hour).

	    All known users can be listed with the "p4 users" command.

	    A user's specification includes his email address, full name,
	    and change review subscription list, but these items are all
	    defaulted when the user's specification is created automatically.
	    This specification can be edited with the "p4 user" command.

	NAMESPACE PROTECTIONS - #2014

	    The protection support introduced in #1507 has been rounded
	    out.  In addition to be able to limit read or write access
	    to the depot based on user name or client host IP address,
	    you can now vary access by depot file name (using the usual
	    wildcards).  Further, a new low grade protection level
	    "list" has been added: this allows access to the namespace
	    but not to the text of any files.  See the extended chapter
	    on protections in the Users Manual.

	SYMBOLIC LINKS - #1923

	    Perforce now understands symbolic links and can revision
	    them.  On NT and OS/2 (where symlinks are not supported) they
	    appear as (small) text files.  A symlink can be treated as
	    an ordinary file by using the "p4 edit -t text" 
	    or "p4 reopen -t text" commands.

Minor New Functionality/Enhancements

	ERROR REPORTING TO STANDARD ERROR - #1933, #1901

	    Error messages from client commands now are written to the
	    client's standard error, so that the many list-producing
	    commands produce _only_ their regularly formatted data on
	    standard output.  Messages about not being able to
	    carry out the command because there was nothing to do (or
	    because the argument matched no files, etc) are considered
	    error messages.

	    The error reporting of failed client operations (such as
	    not being able to find a file) has been tidied up a bit,
	    so that only the essential error information is emitted
	    and the "Error:" flag is omitted.

	CLIENT EXIT STATUS - #1901, #1890

	    If any error message is emitted during the execution of a
	    client command, the client exit status will be non-zero (1).

	NT WILDCARD HANDLING - #1704

	    The NT p4 client executable now performs wildcard expansion,
	    so that it runs well from within the DOS box.  This also
	    affects operation under the Korn Shell, which already does
	    wildcard expansion itself.  Now, to get a wildcard past the
	    client when using the Korn Shell you must quote it twice
	    ('"*"'): once for the Korn Shell and once for the p4 client
	    client.  The p4 client uses the NT setargv.obj module for
	    wildcard expansion.

	FILELOG -L FLAG - #1925

	    "p4 filelog" now takes an optional "-l" flag to produce the
	    full text of change descriptions, similar to "p4 changes".

	PER-USER LICENSING - #1911

	    Previously Perforce was licensed on a per-client workspace
	    basis, with two client workspaces allocated (on average) for
	    each user.  With the advent of user tracking, the licensing
	    is now actually per known user.  This licensing is enforced
	    any time a new user invokes a Perforce client command: if the
	    addition of this user would exceed the licensed number, the
	    user's access is denied.

	    Excess users can be deleted with the "p4 user -d" command,
	    but only if the user to be deleted has no opened files.

	    For sanity's sake, the commands "help", "info", "user", and
	    "users" are excluded from licensing enforcement.

	NEW LICENSE FILE - #1710

	    Perforce servers are now licensed by means of an external
	    license file that sits in the Perforce server root
	    directory.  Previously servers were licensed via fixed-up
	    executables downloaded from the Perforce Web pages, but this
	    required users to update to the latest release just to add
	    more licenses.  The separate license file allows users to
	    download new releases as desired, independent of licensing.
	    License files available to Perforce customers; send email to
	    info@perforce.com for information.

	GUARANTEED CHANGE ORDERING - #1987

	    When a change is submitted it is now renumbered, if necessary,
	    in order to ensure that change numbers are always increasing
	    in time.  This means that a pending change number may not be
	    the same as the final change number, and that there may be gaps
	    in change numbers.  (Bug #126).

	CLIENT-LESS COMMANDS - #1994

	    Certain commands may now be run without having to create a
	    client first: branch, branches, client, clients, describe,
	    fix, job, label, labels, protect, review, user, and users.

	    Further, the following commands can be used outside the
	    context of a client as long as they are not passed arguments
	    referring to local files:  changes, diff2, filelog, files,
	    print, fixes, integed, jobs, reviews.

	    The following commands always need to be run from a client
	    previously created with "p4 client": change, diff, get, have,
	    integ, labelsync, lock, open, opened, refresh, release, reopen,
	    resolve, resolved, submit, unlock, where.

Bugs Fixed

	#1865
	    The messages emitted when a p4 command can do no work have
	    been changed.  The most important is "p4 integrate", whose
	    "Nothing to integrate" message has been replaced with separate
	    messages describing why there is nothing to integrate:  no
	    files in branch view, no files in client view, integrations
	    complete in a pending change, all integrations completed.
	    Messages for "p4 get" and "p4 labelsync" have been enhanced,
	    and now all commands use the same terminology and format
	    when the user provides an argument that affects no files.

	#1863
	    "p4 integrate" now handles synchronizing integrations properly:
	    when an integration results in a copy of the source file onto
	    the target file (via "accept theirs" in "p4 resolve"), "p4
	    integrate" now realizes that those files are in sync at that
	    point and earlier revisions need not be integrated. (Bug #74).

	#1762
	    Under concurrent use "p4 submit" would sometimes complain
	    about database table locking errors.  This has been corrected.
	    (Bug #122).

	#1761
	    The handling of path names around the filesystem root worked
	    poorly: when climbing up to the root using "..", the initial
	    "/" would get dropped.  With a root directory of "/", often
	    an extra "/" would get inserted.  This has been corrected.
	    (Bug #121).

	#1752
	    "p4 help", "p4 change", and "p4 changes" now agree that a
	    change that has been submitted has a status of "submitted",
	    not "closed" or "committed".

	#1750
	    The QNX server left its children as zombie processes, because
	    it failed to wait() for them.  It now collects them properly.
	    (Bug #118).
	
	#1719
	    The "p4 -x file command" flag would only send the first 128
	    lines of the named file as arguments to the command.  It now
	    passes the whole contents of the file as arguments. (Bug #107).

	#1718
	    The rcstoperf.sh script did not handle RCS filenames with
	    @'s in them properly.  This script relies on the p4d server
	    for most of its work, and the p4d server has been changed so
	    that RCS files with @'s in the name are handled better.
	    (Bug #109).

	#1705
	    With an NT server and UNIX client, the output of "p4 diff2"
	    and "p4 describe" had a trailing \r (carriage return) on each
	    line of diff output.  This has been fixed.

	#1698
	    Certain characters are now no longer permitted in identifiers 
	    - user, client, label, branch, job, and file names.  The
	    following characters are prohibited in identifiers:

		o	White space
		o	Non-printable characters
		o	Wildcards (*, %x, or ...)

	    Additionally, the following are prohibited in file names:

		o	Revision identifiers (# or @)

	    Previously these identifiers could contain such letters,
	    but the behavior of Perforce with such idenfiers was irregular
	    or undefined.  (Bug #108).

	#1672
	    Passing a file without a final newline to "p4 -x" would
	    cause the p4 client program to crash.  This has been fixed.

	#1618
	    Two improvements to Perforce's ability to handle a server
	    crash: first, the contents of RCS files maintained by
	    Perforce are now flushed to the disk with fsync() before a
	    change is committed.  Second, if an RCS lock file is found
	    in the depot it is now silently ignored.  Since Perforce
	    does its own locking against concurrent updates, Perforce
	    can safely assume that any RCS lock file is due to a system
	    crash during a previous submit.  (Bug #99).

	#1612
	    On NT and OS/2, "p4 diff" of a binary file would say the
	    files were different even if they were the same, because it
	    was not treating the local file as a binary file.  This has
	    been corrected.

	#1602
	    "p4 reresolve" would try to resolve branched or deleted
	    files, which aside from making no sense would fail because
	    of the lack of a file on the client with which to merge.
	    This has been corrected, and "p4 reresolve" only attempts
	    to resolve those files previously merged using "p4 resolve".
	    (Bug #91).

	#1600
	    If while editing a branch, client. label, job, or change 
	    form you deleted the temporary file holding the form, first
	    the p4 client would complain (rightfully) and then hang.
	    It no longer hangs and instead issues a message that the
	    command has been aborted.  This fix affects both the p4 client
	    and then p4d server.  (Bug #93).

	#1594
	    Under certain circumstances, two users could lock the same
	    file.  This has been corrected.  (Bug #97).

	#1582
	    If "p4 integrate" has to integrate a file that is not on 
	    the client, it will get it first.  Files in that condition
	    were not recognized by "p4 diff" as being opened.  This has
	    been fixed, and "p4 diff" now correctly diffs these files.
	    (Bug #94).

	#1549
	    Checking in a file that was identical to its predecessor would
	    cause mmap failures in the Solaris p4d server.  This has been
	    corrected.  (Bug #88).

	#1547
	    On NT the IP address of the first client to connect to the server
	    was used for all subsequent clients, confusing the protections
	    algorithm.  Now the proper IP address is found.  (Bug #87).


Release #1525, April 1996.
Changes between #1223 and #1525.

Compatibility

	Release #1525 requires a conversion of the database files from
	#1223.  To convert the database, you need only to checkpoint
	the database (using the old p4d program) and restore from the
	checkpoint (using the new p4d program).  Follow the instructions
	in the administration chapter of the users manual on how to use
	checkpoints.

	You can mix #1525 and earlier (#1223, #827) clients and servers,
	but some functionality new to #1525 requires upgraded clients
	and/or servers.

Major New Functionality

	#1507
	    Perforce now has support for assisting in defect tracking
	    through the "jobs" mechanism.  This support can be used in
	    itself as a defect tracking system, but it is mostly meant
	    to mirror the necessary information from an external defect
	    tracking system.  See the new chapter on Jobs in the Users
	    Manual.

	#1507
	    Perforce now has limited support for protecting the depot
	    against unauthorized use.  The protection mechanism is rooted
	    in IP address verification, and allows users and hosts to
	    be given no access, read access, or read/write access to
	    the depot.  In this release, the access control is for the
	    entire depot.  In a future release, the access control will
	    be for arbitrary subsets of the depot name space.

	#1470
	    Labelsync now allows a revision specification to be given
	    with the file argument.  Without the rev spec, labelsync
	    behaves as it did before, using the list of files on the
	    client to populate the label.   If a rev spec is given, then
	    the depot files with the named revision are used instead.

	#1464
	    Labelsync's behavior has been changed to allow labels to be
	    edited selectively.  Labelsync's default behavior remains
	    the same: without any file arguments, it makes the label
	    reflect what the client has (as reported by "p4 have").
	    Previously, if a file argument was given the label would
	    be updated to reflect only the named file(s), deleting any
	    files in the label but not named by the argument.  Now,
	    if a file argument is given those files are _added_ to the
	    label.  If the new -d flag is given, thos files are deleted
	    from the label.  The -d flag without a file argument deletes
	    all files from the label.

	#1493
	    "p4 labelsync" now refuses to update the label unless the
	    invoking user is the owner of the label.  This is a safety
	    feature to keep users from accidentally updating labels.
	    It is not a security feature, as any user can change the
	    owner of a label with the "p4 label" command.  Changing the
	    label owner to a non-existant user name will prevent anyone
	    from updating the label.  (Bug #75).

	    New labels now have owner fields initialized to the user
	    creating the label.  Existing labels can have owners added
	    by using "p4 label" to put an "Onwer: name" line in the
	    label's specification.

	#1352
	    Resolve's prompt has been reworked somewhat.  The plain
	    "accept" has be renamed "accept merge", and a new "accept"
	    now selects the best file to accept, according to the 
	    algorithm used by the automerge option:  if there are no
	    changes in your version, accept theirs; if there are no
	    chagnes in their version, accept yours; otherwise, select
	    the merged file.  The diff commands have been moved around
	    (again), and the plain "diff" now shows your file will change
	    if you accept the merge.  This seems like the most sensible
	    meaning.

	#1351
	    When resolve is presented with two files that have no
	    ancestor, it now presents that differences between the
	    current file and the one being integrated from as "their
	    changes."

Minor New Functionality/Enhancements

	#1506
	    --- DATABASE CONVERSION REQUIRED -- SEE BELOW ---

	    The length of user names has been increased from 20 bytes
	    to 32 bytes.  The length of client, label, and branch names
	    has been increased from 20 to 64 bytes.  It should be noted
	    that the length of files names remains 128 bytes and that
	    client and label names appear as part of file names (in the
	    form //client/path).  The 128 byte limit on file names may
	    impose more of a restriction than the 64 byte limit on client
	    and label names. 

	    CONVERSION NOTES:  the size changes require a conversion of
	    the p4 database.  In this case, the only conversion that is
	    required is to checkpoint the database (using the old p4d
	    program) and restore from the checkpoint (using the new p4d
	    program).  Follow the instructions in the administration
	    chapter of the users manual on how to use checkpoints.

	#1495
	    "p4 changes" now takes a "-s status" flag to limit its 
	    output, where status is either "pending" or "committed".

	#1488
	    The p4 client now gives (hopefully) more helpful messages
	    when it fails to connect to the server.  The misleading 
	    mention of "RPC" has been all but removed.

	#1468
	    When integrating deltas back and forth between a pair of
	    files, the "integrate" command now includes (rather than
	    deliberately excludes) the result of previous merges so
	    that the same conflicts do not need to be revisited.

	#1465
	    The new change specification created by "p4 submit" and
	    "p4 change" now has the change description field above
	    the list of files, rather than at the end of the form.

	#1449
	    p4 changes and p4 jobs now take an optional -l flag to 
	    turn on long output: instead of just printing the initial
	    32 bytes of the change/job description, the long form produces
	    the whole description, indented a tabstop.

	#1391
	    The p4 server can now listen on a specific internet address
	    on hosts with more than one interface.  The most likely use
	    of this is to listen on "localhost", thus preventing any
	    remote connectios to the server.  The format for the listen
	    address is the same as for $P4PORT: "host:port".

	#1390
	    Labelsync reported the old revision number (of the file in
	    the label) when updating a label.  Now it reports the new
	    revision number.

Bug Fixes

	#1512
	    When a p4 get replaces a file with one that is deleted, it 
	    actually tried to transfer the deleted file.  Now it just
	    deletes the file on the client.  (Bug #84).

	#1348
	    NT path handling has been spiffed up a bit: now case is 
	    ignored when comparing the current directory against the
	    client's root: components past the root (most notably the
	    file name) are still case sensitive.  (Bug #52).

	    The p4 client now accepts /'s anywhere in a file name given
	    on the command line.  Previously, it did not allow them in
	    relative paths (../xxx) or in the portion of the path that
	    corresponded to the client's root.  (Bug #57).

	#1343
	    If more than one user had a file opened, only one user could
	    effectively lock it.  Others could lock the file, but neither
	    submit nor unlock would recognize it as being locked. (Bug #86).

	#1336
	    Even though multiple ...'s are not allowed in mappings, they
	    could still be entered, and would cause undesirable results.
	    Now all the p4 commands that manipulate views allow only one
	    ... in each mapping.  (Bug #59).

	#1333
	    When adding large files on BSDI, sometimes the system would
	    hang.  The protocol has now been modified to stream properly
	    even on systems with small kernel buffer queues.

	#1328
	    Submits, locks, and reverts of a large number of files
	    (like in the 1000s) took a long time to get going.  This
	    has been corrected and now these commands perform at speeds
	    comparable to commands like opened and unlock.  (Bug #58).

	#1287
	    Certain commands - edit, resolve, and submit - try to give
	    or revoke write permission for files on the client.  This
	    can fail if the file is not owned by the user invoking the
	    operation.  If this happens, Perforce will now attempt to copy
	    the file (and replace the original) in order to get ownership.
	    This can still fail if the directory is not writable by the
	    user.

	#1273
	    Submitting files with names longer than about 100 bytes would
	    cause the server to crash.  Now file names up to the full 128
	    bytes can be submitted.  Names longer than that generate an
	    error (from "p4 add").  (Bug 48).

	#1267
	    "p4 resolve" on a UNIX client against an NT server would
	    produce ^Ms at the end of each line.  Fixed.  (Bug 47).

	#1224
	    "p4 where" would show duplicate mappings.  This has been
	    fixed.  (Bug 45).


Release Notes for Perforce 
Release #1223, January 1996.
Changes between #827a and #1223.

Highlights

    - Branching model rounded out.
    - New automatic mode (-a) to "resolve".
    - Support for executable binaries and text.
    - New reporting supported with "changes" command
    - Diff commands "diff", "diffhead", and "diffhave" consolidated
    - "diff" and "diff2" can now take label names.
    - New commands 
		    resolved
		    integrated
		    reresolve
		    reopen
		    where
		    info

Compatibility

    Release #1223 is compatible with release #827, with the following
    notes:
    
    o	A #1223 server can use the database files from #827, but because
	it writes addition integration records, database files from #1223
	should not be reused with #827.

    o	You can mix #1223 and #827 clients and servers, but some functionality
	new to #1223 requires upgraded clients and servers.

Branching and integrating

    Enhancements:

	#1165
	    Resolve's "dt" and "dy" commands (diff theirs, diff yours)
	    now compares their/your file against the merged result, rather
	    than the base.  That way you can see the results of editing
	    the result.

	#1120
	    "integrate" now allows a revision range on the file spec.
	    Previously, integrate would insist on integrating all revisions
	    of the source file that had not been integrated into the target
	    file.  Now you can select which revisions are to be integrated.
	    See the user manual for details and examples.

	#1011
	   "resolve" and "resolved" now report the target file in local
	   syntax rather than the //client/... syntax.  

	#1005:
	    "resolve" now takes the -a (auto) and -f (force auto) flags,
	    to invoke an automatic resolve mode.  The -a flag will not accept
	    files with conflicts, while -f will.  Use "p4 help resolve" to
	    see what the automatic semantics are.

        #980
	    If the target file of an integration takes exactly one set of
	    revision from one source file, a reverse integration "credit"
	    is created to prevent having to integrate that change back to
	    the source.

        #967, #992
	    "resolve" now has the variant "reresolve", which causes it to
	    re-resolve previously completed but unsubmitted merges. 

        #979, #992
	    When resolving files opened for integrate, "resolve" now leaves
	    the files read-only after accepting the result.  To edit the
	    file again, use "reresolve file".

        #960
	    "resolved" and "integrated" have been added to the barrage
	    of display command.  The former lists integrations that have
	    been resolved but not submitted.  The latter lists integrations
	    that have been submitted.  To see unresolved integrations, you
	    continue to use "resolve -n".

        #911
	    The "integrate" command now takes an optional -r flag, which
	    says to reverse the individual mappings in the branch view.
	    In this way, the same view may be used for propagating changes
	    both from the source files to the target files as well as
	    back again.

        #823
	    Certain common integration actions - branching itself and
	    accepting the other line's version during merging ("accept
	    theirs" in resolve) - no longer need to be integrated back
	    into the source files.  This is suppressed by the creation
	    of a special integration record at submit time, and prevents
	    a change from pinging back and forth between files related
	    by branch views.

    Bugs

	#1222
	    The priority of branch view mappings was reversed: generic
	    mappings should be at the top, with higher precendence
	    mappings below.  It is interpreted that way.

	#1053
	    Integrating a deleted file insisted that the target file be
	    resolved (and then complained the file was deleted and should
	    be reverted and gotten).  Now integrating a deleted file
	    just deletes the file (pending submission) and does not require
	    a resolve.  (Bug 35).

	#1017
	    If a file was opened for edit and "get" was used to bring
	    in the head rev, "get" would report that the new head rev
	    had to be resolved but would not update some necessary
	    information.  A subsequent "submit" would fail complaining
	    that the file is opened at the wrong rev.  This was introduced
	    in #947.  (Bug 34).

	#1016, #968
	    "resolve" stuck extra text into the result file if the
	    same change was made in both branches of the file (the
	    extra text was the original version).  This has been
	    corrected.  (Bug 33).

	    "resolve" put in a bogus conflict marker if a block of lines
	    changed the same way in both versions of the file to be merged.
	    This has been corrected.  (Bug 33).

        #966
	    The "diff" option in the "resolve" menu diffed a file against
	    itself, producing nothing.  This only happened when performing
	    a "two way" resolve where there was no base file and thus no
	    merge.  This has been corrected.

        #947
	    If a file was opened for edit and the client later updated
	    to the head revision (created by another client), "get" would
	    report that the file "must be resolved."  Subsequent invocations
	    of "get" would repeat the message, even though there was nothing
	    more to resolve.  "Get" no longer makes this mistaken claim.

	    If a file was opened for edit and the client updated to an
	    earlier revision, "get" would get confused and claim the file
	    needed to be resolved but resolve would report that there was
	    nothing to resolve.  Now "get" does not allow getting and older
	    revision of a file opened for edit.

Enhancements

	#1177
	    Perforce now recognizes executable text and binary files
	    and sets their permissions properly on get, submit, edit,
	    revert, and refresh.  New types include xtext, xbinary, and
	    xltext.

	#1051, #1120
	   "changes" now takes an optional file argument.  If a file
	   name is given, "changes" limits its output to changes that
	   affect the named file or have been integrated into the named
	   file.  If the file name contains wildcards, "changes" produces
	   a consolidated list for the collection of files that match
	   the wildcard.  The file name can have a revision range, limiting
	   the output to changes which were made or integrated during that
	   revision range.

	#1152
	    New "p4 where" command reports how current directory (and
	    subdirectories) map through the client view into the depot.
	    If a file name is given on the command line, the mapping for
	    that file name is reported.

	#1061
	    New "p4 info" command displays a short summary of information
	    known about the client and server.

	#1055
	    The "p4 describe" command now has a -s flag to produce a
	    short form.  This form excludes file diffs.

	#1028
	    The p4 client can now compare binary files, and so the "diff"
	    command now supports comparing binary files.  The output
	    is silent if the files are the same and a single message if
	    they are different.

        #981
	    "describe" now shows the time as well as the date of change
	    submission.  This and the "change" command is the only way
	    to display the time of change.

        #972
	    New "reopen" command moves files among changes and changes
	    the file type.  Previously, "open" did this, but now "open" 
	    never does anything to previously opened files.

        #958
	    The output of the "opened", "files" and "integrate" commands
	    have been massaged slightly to make them more consistent with
	    other commands" output.

        #949
	    The formatting of the "changes" and "filelog" has been altered
	    to move the fixed part of the output towards the beginning of the
	    lines and to lengthen the text of the change description.

	#881, #1010, #1184
	    The diffhave and diffhead commands have been renamed:

		    diffhead	-> diff -f #head
		    diffhave	-> diff -f #have

	    Also, "diff" without the -f flag will compare not only
	    files that are opened, but files that are not at the named
	    revision (if a revision is given).

        #881
	    Two new revision specifications are possible:

		        #head		- the head rev (normally the default)
		        #have		- the rev last gotten by the client,
				      synonymous with "@my-client-name".

        #878
	    Both diff and diff2 now allow "@labelname" as revision
	    specifications.  Previously, they accepted only "#revision"
	    and "@changenumber".  Now anyplace where a revision number
	    can be used a label name is permitted as well.

        #854
	    "p4 print" now takes a -q flag to suppress the initial line
	    that displays the file name and revision.

        #817
	    A revision specification can now be used alone with a file
	    name.  It is shorthand for "//depot/..." (i.e. the whole depot).
	    Thus @3 means "//depot/...@3" or the state of the depot at
	    change 3.

Bugs

	#1095
	    The current directory on NT is now forced to lowercase, since 
	    the same directory can show up in different cases in $PWD.  
	    Filenames are not forced, because we need to preserve their
	    case for filenames such as "Makefile".

	#1058
	    "p4 help" did not include "diff2" or "labelsync".  It now does.

	#1054
	    The "p4 need" command has been removed: use "p4 get -n".

	#1018
	    "diff" now diffs against the opened revision of the file (i.e. 
	    the revision resolved to) rather than the revision when the
	    file was opened.

        #982
	    Label, client, and branch names can now be 19 characters in
	    length instead of 18.

        #951
	    Certain combinations of wildcards - such as using ... in the
	    middle of a mapping - would not match file names that they should
	    have matched.  Now ... can be used in the middle of a mapping
	    without problem.  (Bug 31).

        #867
	    Adding files in directories that had multiple view mappings
	    yielded the error "Can't add filenames with wildcards in
	    them." even though there were no wildcards.  Now files can
	    be added in directories that map through more than one line
	    of the client's view.
