Release Notes for Perforce The FAST Software Configuration Management System Introduction This document lists all user-visible changes to the Perforce server (P4D) and command line client (P4) between Release 97.3 and 2002.1. Release notes for P4Win, P4Web, P4WinMerge, CW Plug-in, and SCC Plug-in, as well as supplemental Platform Notes and notes on Internationalization are available separately on the Perforce Documentation web page. Perforce numbers releases YYYY.R/CCCCC, e.g. 2002.1/30547. YYYY is the year; R is the release of that year; CCCCC is the bugfix change level. Each bugfix in these release notes is marked by its change number. Any build includes (1) all bugfixes of all previous releases and (2) all bugfixes of the current release up to the bugfix change level. 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. -------------------------------------------------------------------------- Upgrading From Previous Releases 1. In addition to your usual checkpointing scheme, always checkpoint your server immediately before undertaking an upgrade. 2. If you are upgrading from 97.3 or earlier releases, please see the upgrade note at the end of this file. 3. The 2002.1 server will automatically upgrade 98.2 and later databases if the database contains fewer than 1000 changes. If there are 1000 or more changes, you will need to upgrade the database manually: from the server's P4ROOT directory, issue the command 'p4d -xu'. THESE DATABASE UPGRADES WILL CONSUME A SIGNIFICANT AMOUNT OF SPACE, depending on which releases you are upgrading through. Check the size of the affected tables, and have available prior to upgrading three times that amount of free space (enough for a copy of the table, plus journal entries for deletes and adds). 2002.1: db.changes 2001.1: db.integ, db.have DOWNGRADING AFTER AN UPGRADE IS NOT POSSIBLE. (See changes 29365, 21633, and 21574.) 4. 2002.1 jobs searching supports matching punctuation, but old jobs must be reindexed with the 'p4 jobs -R' command before punctuation in those jobs will be found. (See change 27808). Interoperating With Previous Releases 1. Unless stated otherwise you can intermix any release Perforce client with any release Perforce server, but any functionality new to 2002.1 requires you to upgrade the client and/or the server. See marks in the notes below. * -- requires new p4 client program ** -- requires new p4d server program 2. Beginning with 99.2, remote depots will interoperate between UNIX and NT. Beginning with 98.2, remote depots will interoperate across (98.2 and higher) releases. In 98.1 and before, remote depots will only operate with another server of the same release. -------------------------------------------------------------------------- -------------------------------------------------------------------------- Release 2002.1, April 2002. Major new functionality in 2002.1 Internationalization (I18N) and Localization (L10N) Release 2002.1 incorporates the I18N and L10N changes that went into the 2001.2 release (made available only in Japan). As of 2001.2, the Perforce clients and server have an optional mode of operation where all metadata and some file content are stored in the server in the UTF8 Unicode character set and are translated into the local character set on the client. Additionally, in 2002.1 all error and informational messages returned from the server may be localized by the Perforce administrator. See the accompanying i18nnotes.txt for a full description of Unicode and localization support. Large Installation Performance Enhancements A number of changes have been targeted at large installations (typically those with more than a million files under Perforce control). Pending Changes Speedup - #29365 ** Pending changes in the db.change table are now split into a db.changex table, to speed up the performance of p4win's frequent 'p4 changes -s pending' command invocation. This requires a database upgrade with 'p4d -xu'. Depot Syntax Speedup - #29329 ** To speed p4win's frequent invocations of 'p4 fstat' on files in the explorer tree, a special optimization has been introduced. Because p4win refers to files using depot syntax, normally the server must scan the client's entire list of files to find the named file. This optimization allows the server to find the file directly if and only if the client's view still reflects the files on the client. This is always the case if the client has done a full sync since last changing the view. Bottom line: if p4win's fstat calls are going slow, try syncing the entire client. (Bug #7069). Labels Command Speedup - #30690 ** The "p4 labels" command when supplied with a file argument would run very slowly and potentially lock the system out to all users due to the significant amount of scanning that was required per label. This command has now been optimized to position the rev table rather than scan when looking for a match. (Bug #6531). Larger Database Pagesize - #27795 ** The server's default database page size has been increased from 4k bytes per page to 8k bytes per page. For large tables this results in more efficient packing with less wasted disk space and better performance. Existing databases continue to work unchanged, but to see the improvement a restore from a checkpoint is needed. New MaxScanRows in 'p4 group' - #27952 ** 'p4 group' now has a 'MaxScanRows' field, which can be used to limit the number of rows that can be retrieved from the rev table during an operation. Use MaxScanRows when MaxResults cannot help control lengthy operations (these operations could typically be speeded up by defining the depot filepath more precisely). By default, users have no limit on the size of scans they can perform. Once a user belongs to one or more groups with any limit, however, that user has the maximum of those groups' limits. This allows, for example, an administrator to create a "novice" group with a low limit, thereby affecting only certain users. See 'p4 help group', 'p4 help maxresults' and 'p4 help maxscanrows' for further information. Minor new functionality in 2002.1 #29455 ** 'p4 client -t' now copies client options as well as the view. Same for 'p4 label -t'. (Bug #1066). #28516 ** Server database journalling is now always on, unless explicitly turned off with P4JOURNAL=off. Previously, journalling was disabled if P4JOURNAL was unset and there was no 'journal' file in the server's root directory. The absence of the journal file no longer disables journalling. #28028 ** 'p4 integrate' by default now syncs the target files to the head revision before integrating. To integrate using the current revision had on the client, use the new 'p4 integrate -h' flag. #27808 ** Jobs searching now allows for matching punctuation: in addition to indexing all alphanumeric strings, the job indexer now also indexes all whitespace separated words. So words with embedded punctuation can be matched. To match characters that are normally jobs search expression operators (=^&|()<>), escape them with a \ character. When searching for words with embedded punctuation in text fields, the wildcard (*) operator is useful, as English words often have trailing punctuation (commas, periods, etc). Existing jobs must be reindexed with the 'p4 jobs -R' command for words with punctuation to be found. Warning: this can take considerable time on a system with lots of jobs. It is harmless to interrupt this command or run it more than once. (Bugs #982, #1004, #1010, #5518). #27227 ** "p4 submit" has a new option "-r", this causes files that have been opened for 'add' or 'edit' on the submitted changelist to remain open after the submit has completed. (Bug #449). #26931 ** Labels can now contain deleted revisions. You must give an explicit revision specification in the file argument to 'p4 labelsync' for it to include deleted revisions, because normally 'p4 labelsync' includes only files on the client (and clients can't have deleted revisions). By being able to contain deleted revisions, labels can be better used to control the operation of 'p4 integrate' and 'p4 obliterate'. (Bug #2351, #5516). Bugs fixed since 2002.1/32489 (first release). #53188 ** Some data patterns (mixes of small and large data nearby) could cause the server to crash or hang and corrupt the database. Should no longer occur (Bug #12567, #13182) #39934 ** On NT servers, under certain conditions an internal file rename operation could fail. A retry has been added to this part of the code and extra diagnostics have been enabled to log relevant information in an attempt to track down this problem. #37658 ** 'p4 changes -i' over a large dataset could crash the server due to lack of memory. This has been fixed. (Bug #9514) #36748 * Clients on OSF incorrectly offset file modtimes by one day Submits were one day into the future and syncs would be one day into the past so this problem would only appear if you operate also with non-OSF clients (Bug #9212) #34617 ** View maps with a mix of non-ANSI (high-bit set) characters and ANSI characters (without a high-bit set) might ignore some lines. (bug 8613) #34362 ** On case-insensitive servers (NT) it was possible for a client to be unable to set an internal flag indicating that the client was in-sync with its view specification. This would result in unexpected poor performance of certain commands. (Bug 8404) #33994 ** Some p4 operations (e.g. fstat) executed without a valid client could cause a scan of the have table. This problem was only observed on NT/W2K servers. (Bug #8230) #33784 ** The increment of the journal counter during checkpoint was not itself being journalled. The journal counter is only used to prevent administrators from recovering from the the wrong journal files. The journal counter increment is now again journalled, as it was before 2002.1. (Bug #8201). #33552 ** 'p4 filelog @