Release Notes for P4, the Perforce Command-Line Client, and P4D, the Perforce Server First Release: September 3, 2004 Introduction This document lists all user-visible changes to the Perforce server (P4D) and command line client (P4) between Release 97.3 and 2004.2. 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 the Server DOWNGRADING A 2004.2 SERVER IS NOT POSSIBLE Significant schema upgrades are performed by the 'p4d -xu' command. The 'p4d -xu' command is generally required when upgrading a server with 1000 or more changelists. If a server has fewer than 1000 changelists, it is automatically upgraded when the new server is started. The 'p4d -xu' command is not required for all server upgrades. For example, 'p4d -xu' is not required when upgrading a 2003.2 server to 2004.2, regardless of the number of changelists. But this does not imply that a 2004.2 server can be downgraded to 2003.2. In fact, upgraded servers cannot be downgraded as a result of additional schema modifications that are made as the new server executes. Before Upgrading To upgrade your Perforce server, your Perforce license file must be current. Expired licenses do not work with upgraded servers. In addition to your usual checkpointing scheme, always checkpoint your server immediately before undertaking an upgrade. To ensure that the checkpoint contains the latest information prior to the upgrade, stop the Perforce server and use the 'p4d -r -J -jc' command to make the checkpoint. Significant schema upgrades performed by the 'p4d -xu' command can consume a significant amount of disk space. You will need to ensure that you have in the filesystem where the db.* files are located free space equal to the size of the tables being upgraded, and twice that amount in the filesystem where the journal is located. The significant schema upgrades in each release are: 2003.2: db.user 2003.1: db.depot 2002.2: db.rev, db.working (tempobj entries only) 2002.1: db.changes 2001.1: db.integ, db.have The schema upgrades are cumulative through releases. For example, if you are upgrading a 2002.2 server to 2003.2, both the db.depot and db.user tables will be upgraded by the 'p4d -xu' command. If you are upgrading from 97.3 or earlier releases, please see the upgrade note at the end of this file. Upgrading Unix Platforms If your server has fewer than 1000 changelists or there are no significant schema upgrades required for your upgrade, simply replace your p4d binary with the 2004.2 p4d and restart your server with your site's usual parameters. The server automatically upgrades its schema. If your server has 1000 or more changelists and there are significant schema upgrades required for your upgrade: 1. Replace your p4d binary with the 2004.2 p4d. 2. Issue the 'p4d -r -J -xu' command. This command performs the significant schema upgrades, then exits. 3. Restart your server with your site's usual parameters. Windows Platforms If your server has fewer than 1000 changelists or there are no significant schema upgrades required for your upgrade, simply run the 2004.2 perforce.exe installer, which will restart your Perforce server service. The server automatically upgrades its schema. If your server has 1000 or more changelists and there are significant schema upgrades required for your upgrade: 1. Run the 2004.2 perforce.exe installer. The installer replaces the p4d.exe and p4s.exe executables, but will be unable to restart the Perforce server service since there are significant schema upgrades required. 2. Issue the 'p4d -r -J -xu' command from a command prompt window. This command performs the significant schema upgrades, then exits. 3. Restart your Perforce server service. After Upgrading 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 2004.2 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. -------------------------------------------------------------------------- Major new functionality in 2004.2 SECURITY LEVEL (Authorization and security levels) The new security features introduced in 2003.2 but undocumented are now fully supported. Most of the changes are built upon the existing system which when used correctly provide adequate protection for most development environments. However, this system did not provide for password enforcement, password strength enforcement and allowed unsafe practices to be established. 2004.2 introduces the concept of a perforce server security level, basically the higher the level the greater level of enforcement. In some cases enforcing a greater security level will make the usage too restrictive for some sites where it simply isn't necessary. The new security features do not offer native data encryption. As in previous versions, Perforce recommends SSH or VPN as a means of access over insecure networks. Setting a security level: To provide backwards compatability the default setting for security allows similar authorization as previous versions. To set a security level in the server a super-user must set the new 'security' counter into the system: e.g. p4 counter -f security 1 (server must be stopped/restarted) The following is a list of the values and their action. security feature/function 0 (unset) * 'p4 login' support. 1 * 2003.2+ clients enforce passwords * 2003.2+ clients require strong passwords 2 * cannot modify password through 'p4 user' * cannot modify password through 'p4 passwd -O -P' * pre-2003.2 clients cannot set password * pre-2003.2 clients cannot use login * unverified strength passwords must be changed * passwords no longer stored/retrieved from registry (NT) 3 * 'p4 login' tickets are the only way to connect to a server, passwords are no longer accepted. NEW LOGIN/LOGOUT COMMANDS PROVIDE PERFORCE ACCESS THROUGH TICKETS The new 'p4 login' command allows a user to establish an authorized connection to the Perforce server by a ticket granting mechanism. A session can be terminated by issuing a 'p4 logout' command. See 'p4 help login/logout' for usage. New field 'Timeout' in 'p4 group' 'p4 group' now has a 'Timeout' field, which can be used to change the default (12 hours) login timeout value for a group of users. This value represents the number of seconds that an issued ticket from the server will be valid for. NEW TRIGGER SUPPORT (mid-submit, post-submit and forms) 'p4 triggers' now supports mid- and post-submit triggers in addition to the existing pre-submit ones. mid-submit triggers happen after file transfer and use a limited set of commands to access the file content via the special revision specification @=change, where change is the pending changelist number. post-submit triggers happen after the commit and therefore cannot stop the operation. (Bug #1651, #1929, #11861) Also, 'p4 triggers' supports triggers on all forms (like 'p4 branch' and 'p4 user'). There are three triggers available: 'out', 'in', and 'save'. An 'out' trigger is run form when the form is generated; an 'in' trigger is run when the form is being saved, but before the server parses it. Both 'out' and 'in' can modify the form. A 'save' trigger is run after the form is parsed and validated by the server. A 'save' trigger cannot modify the form. (Bug #796, #1651, #9738, #10536) NEW INDIRECT INTEGRATION DEFAULT 'p4 integrate' now always considers indirect integrations through intermediate branchs when determining that files are related and what changes need to be integrated. The direct/indirect option in branch specifications has been removed as all integrations will be considered indirect. Related is that 'p4 integrate' may select a base for merge resolution from a common ancestor which is neither the source nor the target file. NEW SMART RESOLVE LOGIC Conflict resolution with 'p4 resolve' has been changed. The new logic reduces conflicting regions with more complex detection of commonality of changes. FILEPATHS THAT CONTAIN CHARACTERS @#%* CAN NOW BE ADDED TO THE DEPOT Previously the special characters "@#%*" could not be included in a file submitted to the repository, instead an error would be generated. As of this release the Perforce command 'p4 add -f' will allow these special characters to be included as part of a filepath. Without the '-f' option an error message will be generated for files containing wildcards. Once added these files can only be referred to in their formatted syntax. For example 'p4 add foo#bar' will result in a file being submitted under the formatted name 'foo%23bar', notice that the '#' gets translated to it ascii hexadecimal represented value '%23'. The syntax to edit the file once it has been submitted would therefore be 'p4 edit foo%23bar'. Perforce commands like 'p4 have' and 'p4 fstat' will show both formatted and local (filesystem) names. These filenames will of course be expanded back to their original submitted name when synced down onto client machines. (Bug #1339, #13270). Note that due to this change, the wildcard %d used in reordering filepaths in viewspecs has now changed to %%d. NEW TAG COMMAND PROVIDES EASY WAY TO ASSIGN A LABEL TO A FILELIST Similar in syntax to the more advanced 'p4 labelsync' command 'p4 tag' allows the user to tag files with a label without requiring a client spec. See 'p4 help tag' for further details. (Bug #9903). -------------------------------------------------------------------------- Minor new functionality in 2004.2 #82815 ** Servers running on some versions of Linux prior to 2.6.11 could be prone to seeing sporadic zombie processes. Although this is a Linux kernel bug this change provides a workaround for those customers who cannot obtain a later release of the fixed kernel. (Bug #17328). #58026 ** 'p4 fstat' has two new flags. The '-O' flag used to request extra information that is usually suppressed and the '-R' flag that is used to restrict output depending on certain criteria. A number of old fstat flags have been folded into these new options. See 'p4 help fstat' for details. (Bug #13343) #56674 ** 'p4 integrate -Di' allows the integrate command to find a base for file merge prior to the latest add of the source file. That is if a source file was deleted and recreated (via add or a branch) those revisions prior to the add could provide a base for integration. This is intended to support cases where files are deleted and readded but still maintain content continuity across the delete. (Bug #11929) #56035 ** 'p4 submit -r' now supports reopening of files that have been branched. (Bug #13380). #56034 ** The 'p4 integrate' command can now determine if a base for merge resolution lies on any ancestor version even if that version is a file which is neither the source nor the target. The base file and version is reported by a change in the output of 'p4 integrate', 'p4 resolve', and 'p4 resolved' if a '-o' option is given with those commands. (Bug #413) #55851 ** The new 'p4 integrate' default of considering indirect integration history allows the command to refuse baseless merges while considering indirect integrations when the -i and -I flags are not supplied. Changes to help descriptions and spec descriptions and problems regarding integrate and branch are corrected. (Bug #3757, #9034, #10740, #11631) #53703 ** 'p4 fstat' has a new flag '-e #changelist'. When this option is selected only files that are affected by this changelist are displayed. (Bug #13258) #53137 ** 'p4 fstat' adds 'type' to its list of output fields, this field will only be displayed if the file is opened. (Bug #13259). #52894 ** 'p4 labelsync' is now atomic in its update of the label table. Previously if a user issued a 'p4 sync //...@labelname' command during a labelsync operation (of the same label) it could be possible to get an inconsistent sync. (Bug #13184). #52329 * ** Files stored as compressed binary (most binary files) are now left compressed over the wire and uncompressed only when they reach the client. (Previously, they were uncompressed on the server and sent to the client that way.) This new behavior is not optional, and is unaffected by the client's "compress" option, which continues to compress all data between the client and server. #51751 ** 'p4 monitor' now sports a '-e' flag to allow superusers to see more about a users environment. The '-e' flag adds the client program name (if known), client name and host address to the list of fields displayed. (Bug #12737) #50570 * P4CHARSET now supports iso8859-15 which is essentially latin-1 with the Euro currency symbol. #50459 ** Overlay (+) mappings are now supported in client views. This allows a client to overlay a sparse tree from the depot on top of a denser on already mapped on the client. Overlay mappings are specifically prohibited in branch views, and have no special effect in label or other views. Bugs fixed since 2004.2/68597 (first release) #85275 ** An integrate command may miss that a delete needs to be integrated when there are multiple levels of indirection between the source and target. Fixed. (Bug #18652). #84047 ** Indirect Integrations involving recently branched files which are then deleted via integration might stop propagating the delete via indirect integrations. (Bug #17233) #83213 * ** Resolve/merge might miss code deletes during resolve or repeat code in a conflict region just before that conflict region. Fixed (Bug #18297, #18348) #81443 * ** During change resolution via p4 resolve an 'accept theirs' could leave a file on the client which does not match the server's original 'theirs' file. (Bug #17890) #80025 * ** Problem with resolve/merge duplicating code when the base file has extra lines at the end that the source and target file do not has been fixed. (Bug #17695) #79969 ** p4 filelog -i would show details of files for which the user has no permissions if those files were branched to files the user has access to. Now, filelog -i will silently not visit ancestor files which the user does not have permission to inspect. (Bug #17691) #79733 ** Triggers were inheriting too many handles from the server process on Windows and could exhaust a system wide handle resource limit. Critical handles no longer inheritied. (Bug #17654) #79498 ** Application-licensed servers cannot be accessed remotely, this has been fixed (Bug #14978). #79383 * MacOS X fix 78626 for problems with temporary files broke p4 login and the P4 API's rename operation in some cases. p4 login fixed and temporary file problem fix revised. (Bug #17605, #17399) #78626 * P4 clients on MacOS X which change files not owned by the user who runs the p4 client may encounter crashs and many temporary files left after the crash. Fixed. (Bug #17399) #76944 ** Prevent server from exiting prematurely on encountering a lock upgrade problem. (Bug #17078) #76880 * ** Resolve logic to expand common change regions could cause crashes or bad merges. Changed to only rarely expand common changes when changes align at start. (Bug #16991) #76510 ** 'p4 fix' of a job against a non-existent changelist could result in a server crash, this has been fixed (Bug #16959). #75008 ** 'p4 fstat -W' has been speeded up by removing the redundant db.have client file scan. (Bug #16031). #74829 ** Resolve might cause a server crash or repeat the whole file contents as a conflict in rare cases. Fixed. (Bug #16596) #73359 ** Bug fix #72493 introduced another possible crash. Revised that fix to avoid the crash. Diffs may report slightly differently with this revised fix. (Bugs #16118, #16425, #16248) #73084 ** With maxResults or maxScanRows set with 'p4 group', changing your client view to map files to a different location could result in being unable to refer to existing files in the client workspace using depot syntax (//depot/name). This has been corrected. (Bug #16205). #72935 ** Trying to sync a compressed binary file from a pre-2004.2 remote server would result in the error: "Operation 'rmt-FileFetch' failed. Unsupported librarian file type 7!" This has been fixed (Bug #15831). #72642 ** Integrate might miss files which need integration when there is a mix of cherry picked integrations and those which are not in intermediate integrations when searching for indirect integration credits. Fixed. (Bug #16141) #72638 * ** Resolve might not detect conflicts when the two files have a change which starts as a duplicate, becomes a conflict, then one file has a change. Fixed. (Bug #16142) #72493 * ** Resolve might cause the server to crash. Crash was due to reading past the end of the yours file. Fixed. (Bug #16118) #71759 * ** The new resolve logic might cause the server to crash. Would happen on very complex merges with overlapping changes and similar regions. Fixed. (Bug #15968) #71497 * ** The new resolve logic might loop consuming all CPU in the server or merge tool when the two files being merged are substantially the same but with many small fragments in common with the base. Fixed, but more cases may be reported as conflicts than before this fix. (Bug #15930). #71324 ** The variable '%change%' for submit triggers is no longer available. This change corrects this omission (Bug #15597). #70948 * ** The new resolve logic might loop consuming all CPU in the server or merge tool when blocks of lines are shuffled with few actual new lines or lines really removed. Fixed. (Bug #15867) #70343 * ** The new resolve logic might drop a line in the following situation: * There is a change common to the 'theirs' and 'yours' files. * Just after that change a line in all files matches a line at the end of a change in one but not both of the 'theirs' and 'yours' files. When this problem happens that common line is lost at end of the insert block which is not common. Servers with versions between 69424 and this fix actually reported a conflict in this case and the conflicting base case would report lines already merged. Fixed. (Bug #15751) #70281 ** 'p4 obliterate' cannot distinguish between an already deleted archive file and failure to undo a lazy copy due to lack of disk space, this can lead to archive data loss. This has been fixed by backing out change #45574. (Bug #15756). #69739 ** 'p4 monitor show' could crash the server on SGI due to large pid value. This has been fixed (Bug #15657). #69731 ** Client server would deadlock with the server on a Linux machine. Reverted change 55835 so that we once again look at the OS TCP send buffer size rather than the receive buffer and we reduced the maximum expected amount of returned data to 16000 bytes. (himark limit) (Bug #15606) #69727 ** Integrations with source revisions ranges specified (so called cherry picked integrations) might choose the base on the target file instead of the source file. Fixed. (Bug #15656) #69643 ** The handling of 'p4 sync @=changelist' accidentally changed to cause files not in the changelist to be removed from the client. This syntax is used by p4win to speed up syncing a single change. Now 'p4 sync @=changelist' again means the same as 'p4 sync @changelist,changelist' as it should, and only affects the files in the given changelist. (Bug #15640) #69424 * ** The new resolve logic could report conflicting regions as too small and those lines would appear to not be conflicting. If that happened, sometimes lines would also be omitted from the end of the file. (Bug #15425) #69124 * Due to an inconsistent implementation of a specific system call on LINUX, it was possible for p4 clients such as p4v to consume lots of CPU and appear to hang. This has been fixed (Bug #15538). #69080 * ** The new resolve logic could duplicate lines in the result if accept theirs were selected interactively from a client. Fixed, however there may be minor differences in the report of fragment counts regarding differences during result and differences in reported common lines. Standalone GUI merge clients are affected. (Bug #15502) Bugs fixed in 2004.2 #65225 ** The Perforce Windows Service now shuts down normally during a system reboot. Before it was terminated by the Service Control Manager. (Bug #13257) #61038 ** Saving a client spec with view arguments to depots which the user has no access (i.e. no 'list' access or better as granted by 'p4 protect') could cause the server to crash. (Bug #14462). #60787 ** Some passwords greater than 16 characters would not be recognized after being set by the user, this has been fixed (Bug #14431). #60299 ** The server will now recognize a license file called "license.txt" as well as the default one "license". This will make installation easier on Windows platforms where often the file has to be renamed before the server can be started correctly. (Bug #14461) #59047 ** Archive files with redundant versions of revision text and ancestral revisions of such a revision can be read properly. (Bug #13954) #58393 ** Mac OS X now uses Unix permissions instead of HFS locking to prevent edits to a file. If it detects a file has the HFS lock set, it will convert it to the new system. HFS locks will never be set by Perforce. (Bug #7096, #11534) #58391 ** Syncing or opening links for edit will no longer change the flags on the files pointed to by the link, but will affect the link itself. Mac OS X only. (Bug #13639, #13640) #58964 ** Archive files with missing revision contents but revision listed in archive header will no longer crash the server. (Bug #14229) #57966 ** Jobs with empty names can no longer be created (but they can be deleted). (Bug #14141). #57268 ** 'p4 login' tickets would not work against a proxy server, this has been fixed. (Bug #13931). #57034 ** After 'p4 verify -u' had been used against the revisions in a spec depot, all new revisions would be reported as 'BAD' by 'p4 verify'. This was caused by the server incorrectly reusing the checksum of the previous revision. This fault has now been fixed. (Bug #13096) #57029 * Client connections would fail if P4PORT specified a hostname starting with a digit. This has been fixed (Bug #4796) #56972 ** 'p4 dirs' is no longer limited by the number of directories it can report. (Bug #13803). #55835 ** Client server would deadlock if the server's operating system reported more TCP buffer space available than was really available typically happens if a server has been configured with very large TCP buffers. p4d is now more conservative and tries to keep less than 30000 bytes expected in its receive buffer. Also, measure the OS TCP receive buffer rather than the send buffer for this setting (himark limit) (Bug #13364) #55389 ** Under certain conditions where old tempobjs and new tempobjs were being submitted together it was possible that some of the new tempobj archive files would not be deleted. This has been fixed (Bug #13628). #54731 ** During a 'p4 submit' operation it was possible for another Perforce client (same P4USER, same P4CLIENT) to interfere with the operation by (for example) reverting files currently being submitted. Checks have now been put in place that make sure that this cannot happen. Should such a change be detected 'p4 submit' will issue the error message "Files newly opened or reverted during submission" and abort. (Bug #13279, #4104) #54050 ** Missing '%' character in a 'p4 triggers' command string could cause a server crash during a submit. This has been fixed. (Bug #13346). #53436 * ** Text file diffs would rarely produce non-optimal diffs on small files with short lines. (Bug #13228) #51219 ** Merely adding or removing a "-" to the mapping of a trigger table line of 'p4 triggers' would fail to be recognized as a change to the table. This has been fixed. (Bug #12789) #50451 ** By remapping a file opened for edit to another depot file, and then syncing that depot file using depot syntax, it was possible to forget that the file was opened. This has been fixed. (Bug #1445) #50435 * ** 'p4 diff2' now always displays '' to indicate "no file". Previously '< none >' was used on the left side. Users requiring the old behaviour for scripts or applications can set the protocol variable "api" to a pre 2004.2 value for example -Zapi=56. (Bug #2127) #50078 ** 'p4 client' and similar commands that edit specs could cause a server crash if a view argument was preceeded by a double-quote with no matching end quote. This has been fixed (Bug #13730). -------------------------------------------------------------------------- Major new functionality in 2003.2 Performance Improvements 2003.2 incorporates a number of changes addressed at the performance of large installations. While these changes were tested against a server of 1M files they should, of course, benefit all servers to some degree. Optimization for frequent syncs - #47694 ** A narrow optimization was made for large client workspaces that do frequent 'p4 sync' commands, typically automated build or test client workspaces. The syntax 'p4 sync @changelist,#head' now makes use of a database index to make its speed related to the number of files affected since the named changelist, rather than the number of files already in the client workspace. To take advantage of this, scripted build or test clients must remember a recent changelist number and sync to changes since that changelist. The provided changelist can be earlier than that previously synced, but the closer it is the faster. This optimization is targeted towards automated client workspaces, because they are in a position to track a recent changelist number. Further, interactive users typically don't sync all of a large client workspace at once. Label use speedups - #47813, #47771 ** Specifying revisions using file@label,label, where the label doesn't contain the named file, no longer causes quadratic behavior. (Bug #11540) Specifying revisions using @label, where the label doesn't contain revisions from a remote depot, will no longer access the remote depot. (Bug #7225) Locking and memory use improvements - #47939, #47402, #46797 ** Concurrency and memory use on 'p4 sync' and 'p4 integrate' have been improved by freeing up temporary resources earlier. Subtle database locking improvements have been made. Previously, any command that could expect a revision specification locked tables (such as db.have and db.label) in anticipation of needing them. Now they are only locked if the command actually makes use of them by including a @client or @label revision. 'p4 sync' now batches its updates to benefit from the internal cache and reduce lock contention. (Bug #9893). Speedups for large client views and protections tables - #48061 ** Large client views or protection tables should no longer slow 'p4 sync' or 'p4 integrate' quite so severely. Indirect integration much faster - #47038 ** Performance of 'p4 integrate -I', which looks at intermediate integations when determining a base, has been significantly improved. Its performance should now be similar to the normal direct integration only case. (Bug #10587). Minor new functionality in 2003.2 #50484 ** 'p4 annotate' now sports a -c flag: output change numbers instead of revision numbers with each line of the file. #48532 ** Depots to which the user has no access (i.e. no 'list' access or better as granted by 'p4 protect') no longer show up in the output of 'p4 depots'. Nor do they appear in the default branch, client, and label views. (Bug #11969). #47719 * ** The MD5 digest (fingerprint) of files are now computed and stored during submit. For best performance, use both a new 2003.2 client as well as server, as the new 2003.2 client programs offload the MD5 computation from the server. (Bug #2696). #47373 * 'p4 diff -db|-dw' now ignores line-ending differences as well as whitespace. This is very useful when used in a mixed platform environment. (Bug #11639). #46947 * 'p4 diff' can now ignore line-ending differences when used with the flag "-dl". This is very useful when used in a mixed platform environment. (Bug #4654). #46649 ** 'p4 integ' has an additional option -D, which allows the user to specify whether source or target deleted revisions are okay to integrate around. See 'p4 help integ' for further details. Bugs fixed since 2003.2/51929 (first release). #68583 ** 'p4 changes -m1 ' where the filepath does not exist can cause a scan of the revcx table. This command can now be controlled with the maxscanrows limit, also it is interruptable by the 'p4 monitor terminate' command. (Bug #15421). #68580 ** On some platforms (windows, HP) during high concurrency the server errorlog could contain truncated or incomplete output. This has been fixed (Bug #15356). #62096 ** The performance of //filepath/...@changeno,@changeno declined for some commands in 2003.2. This problem could also cause maxresults or maxscanrows to be exceeded when in prior versions they would not be. This has been fixed (Bug #14588). #61159 ** Under certain circumstances if an error occurred during an internal sort, the server could exit. The error could be due to out-of-memory conditions or maxResults exceeded. This has been fixed (Bug #14550). #59667 ** RCS files could be truncated during sync if the number of lines in the file was greater than 10,000,000. Typically RCS files are smaller and are not the best archive format for very large files (use ctext instead). This limit has however been raised significantly to prevent the truncation. (Bug #14115). #59362 ** Integrating a ktext file to a non-ktext file could result in a bad digest being copied to the target of a lazy copy. The problem would be reported by a subsequent verify command. (Bug #13495). #56802 ** Windows/NT Server performance could degrade over time due to heap memory fragmentation. This change links in a third party memory manager which has shown to not fragment memory and to significantly improve performance on multi-cpu hardware. (Bug #13378). #56585 ** Increase the number of directories that 'p4 dirs' can report about to 100000. (Bug #13803). #54142 * ** Some platforms may exhibit problems setting a password using 'p4 passwd'. This would result in either an error message "Bad parameters passed to mangler!" or that a subsequent passing of the password would be rejected. This has only been observed on OSF (Digital UNIX). (Bug #13427). #53591 ** Using a 2003.1 client (or previous) against a 2003.2 server could result in the server not setting the correct modTime at submit. Subsequent syncs would observe the incorrect time, this has only been reproduced against a 2003.2 server running windows OS. This has been fixed. (Bug #13353). #53371 ** p4 integ -I could report all revisions integrated incorrectly or choose the wrong base for integration when a branch of a common ancester is edited and integrated into the source file. Fixed. (Bug #13115, #13234) #52835 ** The Perforce server could incorrectly report a lack of available memory on the Mac OS X platform. (Bug #13198) #52747 ** 'p4 files //...@labelname' or similar could return incomplete results if some of the files involved were from a remote depot. This has been fixed. (Bug #13162). #52650 ** The @change,change syntax, where change was old, could be slower in 2003.2 than 2003.1. (This syntax is generated by p4win and other programs when integrating by change number.) This has been optimized to be as fast as the new @=change syntax. (Bug #13150). #52585 ** After upgrading to 2003.2 some user passwords may not work anymore. This upgrade process has now been fixed. (Bug #13164) #52474 ** Users without access could create (useless) entries for themselves in the users table, consuming a user license. They can no longer do so. This was new to 2003.2. (Bug #13098) Bugs fixed in 2003.2 #51358 ** 'p4 depots' would include depots where the user had been denied list access. This has been fixed. (Bug #12238) #51351 * 'p4 diff' of an "apple" type file on an non-mac platform would result in the erroneous error "WARNING: AppleSingle/Double corrupted." This has been fixed. (Bug #11023) #51346 * ** Merge resolution could silently accept an insert twice if the two versions being merged both inserted text near another change. Conflicts are now reported. (Bug #12708, #12768) #51293 In certain cases using 'p4d -xf 925' to correct inconsistencies between the db.locks and db.working tables could erroneously delete lock records. This has been fixed (Bug #12694). #50946 NT only - need to perform service pack check after -V option has been processed. If not then the installer can fail. (Bug #12693) #50517 ** An unlikely combination of data might cause database corruption especially during checkpoint recovery. The cause of corruption has been fixed (Bug #12567) #50158 ** On Windows the server might crash if the error log file became locked say during backup or a long copy operation. Now, instead of crashing we silently drop errors if we can not write to the log file. Because of this, administrators should be careful not to lock the error log file for any significant time such as due to leaving an editor open on it. Consider frequent log changes or copying the log file prior to viewing it with an editor. (Bug #12403) #50127 ** RCS files are limited to 2 Gigabytes. However on platforms that have large file support it is possible to write one greater than 2 Gigabytes. A file that is of this size should be stored as compressed text. This change prevents the writing of such a large file and suggests the appropriate file type change. (Bug #11837). #48418 ** p4d -jr (journal and checkpoint recovery) run concurrently with regular server operation might cause database corruption. This is primarily seen with p4jrep. The cause of corruption has been fixed. (Bug #11817). #48343 ** The user password as stored in the db.user table (and logged in the journal) is no longer directly usable as a password on the client. (Bug #11544). #48194 ** 'p4 integrate -I' indirect integration support would sometimes determine the wrong base for integrations and/or report that integrations were not needed or that they were needed when they were not. (Bug #10912, #11831, #12129). #47628 ** 'p4d -xi' which sets the server into i18n mode after checking that the depot contains only UTF-8 conforming metadata did not detect some invalid UTF-8 sequences. This check should now detect more invalid sequences. (Bug #11678). #47518 ** Some platforms could only start the server in "restricted mode" if their designated listening port was greater than 32767. This has been corrected (Bug #11689). #48707 * 'p4 delete' on a file of type "applefile" could terminate with a "Fatal client error" if either the data or resource forks had been manually deleted from the workspace. This problem has been fixed. (Bug #11982). #48448 ** 'p4 submit' could cause the server to crash when trying to submit a file when the user did not have the appropriate permission to do so. (Bug #11920). #46400 * In Unicode mode clients, error and informational messages which have some characters which can not be displayed properly in the character set specified by P4CHARSET will now display the message with the untranslateable characters as '?'. Prior to this change the whole message would not be shown, only a 'no translation' error message. #46044 ** Text files with keyword expansion (ktext, text+k) were not always handled properly when the proxy was in use. This is fixed. A new p4p or p4d is required, but performance is best if both the new p4p and p4d is in use. (Bug 11212). #45941 ** 'p4 verify -q' would compute digests of archive files unnecessarily adding to the time taken in running this command. (Bug 11305). #45574 ** 'p4 obliterate' would halt if it tried to unlink a lazy copy and failed because the archive was already removed. This change causes the server to issue a warning message but continue processing. #45067 ** 'p4 fstat -W' would be slow to return data even if no files were open on the client. The command has now been optimized to make better use of the db.working table as an index. (Bug 9252). -------------------------------------------------------------------------- -------------------------------------------------------------------------- Major new functionality in 2003.1 2003.1 includes a number of as yet undocumented internal changes required for versioning and configuring of p4 specs. NEW MONITOR COMMAND DISPLAYS STATUS OF RUNNING P4 PROCESSES - #41063 ** The new 'p4 monitor' command displays the status of current running p4 processes. It is functionally similar to the UNIX 'ps' command. A perforce administrator can also use monitor to terminate long running processes. See 'p4 help monitor' for usage. (Bug #2931, #9889). Minor new functionality in 2003.1 #43840 * ** 'p4 resolve -a' of a binary file where either "yours" or "theirs" has changed from the base now does an automatic "accept theirs/yours", a conflict will still require manual selection. Interactive resolve will now suggest "at/ay" as appropriate. (Bug #5547). #39123 ** The new option 'p4d -c command' runs the command while the database tables are locked. (Bug #9887). #38864 ** 'p4 changes' has an additional option "-t" when specified will display the time as well as the date. (Bug #3224) Bugs fixed since 2003.1/46260 (first release). #48707 * 'p4 delete' on a file of type "applefile" could terminate with a "Fatal client error" if either the data or resource forks had been manually deleted from the workspace. This problem has been fixed. (Bug #11982). #48448 ** 'p4 submit' could cause the server to crash when trying to submit a file when the user did not have the appropriate permission to do so. (Bug #11920). #48379 ** p4d -jr (journal and checkpoint recovery) run concurrently with regular server operation might cause database corruption. This is primarily seen with p4jrep. The cause of corruption has been fixed (Bug #11817) #47686 ** 'p4 add' would ignore the executable bit for applefiles that had '+x' user permissions. This change causes those files to be submitted as 'apple+x' by default. Bugs fixed in 2003.1 #46143 ** 'p4 obliterate' would halt if it tried to unlink a lazy copy and failed because the archive was already removed. This change causes the server to issue a warning message but continue processing. #45952 ** Linux Perforce server was incorrectly reporting out of memory when close to 1GB had been consumed. (Bug #11363). #45779 ** Setting the JobStatus field on a change form would not always propagate the fix status to the included jobs. (Bug #11312). #47686 ** 'p4 add' would ignore the executable bit for applefiles that had '+x' user permissions. This change causes those files to be submitted as 'apple+x' by default. (Bug 11409) #45010 * On Windows/NT a sync "delete" action that tries to unlink a busy file fails to report the error. In addition the db.have table is incorrectly updated as if the delete actual occurred, this has been corrected. (Bug #11068). #44920 ** Some translated error messages that have been stored in perforce in a foreign language were being obscured by in-built English language versions. This has been fixed. (Bug #11173). #44136 * On Windows/NT a manual 'p4 resolve' could result in edits being lost if the target (local file) was busy during a rename operation. This change allows the user to close down the editor or whatever process is holding on to the local file and continue without losing work. (Bug #953). #44444 * ** 'p4 diff -db' or '-dw' could crash if both files ended in identical lines of one space without a trailing newline. This has been fixed. (Bug #11026). #43856 ** 'p4 change -o changelist#' no longer requires a valid client to be able to dump change information. (Bug #10980). #43660 ** The 97.3 (and earlier) p4win can no longer edit any form data against a 2003.1 or later server. This all but obsoletes the 97.3 p4win. #43605 * 'p4 -G job -o' with a custom jobspec that had an invalid preset (usually a value like 'set-me') failed, because the 'p4 -G' support was inadvertantly trying to validate the fields of the blank jobspec. Now 'p4 -G' doesn't validate the fields of the forms being output. #43555 ** 'p4 client' allowed the user to input a single double-quote character into the clientspec 'Root' field. This could lead to corruption of the spec requiring it to be recreated. An error is now raised to prevent this happening. (Bug #10569). #43360 ** 'p4 obliterate' no longer selects all revisions of a file when supplied with #head or #head,#head as its file revision spec. Some other commands that were not obeying #head,#head semantics correctly have also been fixed by this change. (Bug #10883). #43205 ** Access to remote depots was requiring an extra user license to enable the connection on the remote site, this has been fixed. (Bug #2128) #42761 ** The diff algorithm used internally by perforce by the various p4 diff/merge commands has been altered to provide better results when run against large text files (between 10000 and 50000 lines). (Bug #10840) #42269 ** p4d no longer holds the error log file open so that it can be renamed/moved without needing to stop the running p4d. (Bug #606) #42258 ** 'p4 client -d' has now been optimized so that during the removal of client data it no longer blocks other users. (Bug #9519). #41499 ** 'p4 sync' now completes all deletes before adding any files to a client's workspace. By performing the 'sync' in this order the amount of disk space required by the client is kept to a minimum. (Bug #607). #39841 ** 'p4 resolve' and other Perforce merge tools will no longer report as conflicting changes on adjacent lines which do not strictly overlap. This should result in fewer conflicting file merges. (Bug #3811, #7912) #38826 * On Windows/NT clients a failed 'sync' due to a file access issue (e.g. file in use) would leave the file writeable. This would cause a subsequent 'sync' to fail with the message "Can't clobber writeable file ". This has been fixed (Bug #786). #38730 ** Case-insensitive servers (Windows) could inadvertently change the case of certain entity names (e.g. client name) when referenced with a non-matching name. For example the client name 'myclient' could be changed to 'MYclient' with the following command 'p4 files ...@MYclient'. This has been fixed (Bug #9566). #38395 ** Previously installations that did not create a depot "depot" would still get a viewspec entry for one each time they created a new client. Now new installations will come initialized with this default depot which can be deleted if not required. Upgraded installations will have an entry created if necessary (i.e. there are "//depot" entries already in existence). If the installation has no reference to any "//depot" file then the depot "depot" will no longer appear in client specifications. (Bug #5960) -------------------------------------------------------------------------- -------------------------------------------------------------------------- Major new functionality in 2002.2 INTEGRATE ACROSS DISTANT BRANCHES - #35537 ** 'p4 integrate' now fully handles merging changes between branches that don't have a direct parent/child relationship. This occurs often when, say, both a release line and a development line are branched from a main line and changes must be merged directly from the development line to the release line. Previously, users had to rely on instructions in technical note #9 to ensure that the Perforce server chose the right base revision for merging. Now an updated option to 'p4 integrate' does the work. The '-I' option looks for "indirect" integration history through intermediate files when determining the base for merging. This makes it able to handle files distantly related by branching, not just those with a direct parent/child relationship. The new branch option 'indirect' implies 'p4 integrate -I' for the branch, so that it need not be passed on the command line. While it is harmless to use the '-I' flag for directly related branches, it is slower. See 'p4 help integrate' and 'p4 help resolve' for updated descriptions of their operation. (Bug #413, #9323). NEW ANNOTATE COMMAND SHOWS HISTORY OF LINES IN A FILE - #35149 ** The new 'p4 annotate' command displays the lines of a file along with the number of the revision that introduced each line. It is functionally similar to the CVS annotate command, except that it has the option to show deleted lines and note both the revision of introduction and deletion. See 'p4 help annotate' for usage. (Bug #574). SHARING CLIENTS USING MULTIPLE CLIENT ROOTS - #34879 ** Client workspaces that are shared across multiple platforms can now be better accomodated by the ability to specify multiple client roots. If the same workspace is accessed from different hosts, the same set of client workspace files can appear with a different root directory. Previously, only one root could be given in the client spec, and the user had to change it manually as he moved among platforms. Now 'p4 client' supports up to three (3) client roots, one main (named "Root") and two alternates (named "AltRoots" ). The client's current working directory is tried against all three, and the first one that matches is used. If none match, the main is used anyhow. 'p4 info' reports the applicable root. This support allows for client roots shared via multiple UNIX paths with symlinks, shared via NFS or Windows shares, or even between MacOS Classic and MacOS X. When used with the 'p4 client' LineEnd 'share' option, client workspaces can be effectively shared between UNIX and Windows. See 'p4 help client' for details on using multiple client roots. (Bug #4471, #6200, #6243, #6275, #6521, #7268) SPRUCING UP DIFFS The various commands that diff files have seen some enhancements to make them more compatible with the GNU diff and patch programs. Ignoring whitespace - #31144, #31078 * ** 'p4 diff', 'p4 diff2', 'p4 describe', and 'p4 resolve' now can ignore whitespace changes, as the GNU diff does. The -db flag ignores changes in horizontal whitespace, and the -dw flag ignores horizontal whitespace altogether. 'p4 resolve' also passes the flags to the diff option in resolve dialog. Note that 'p4 resolve' will use text from the client (aka "yours") file where the files differ only in whitespace. 'p4 diff' requires a p4 client upgrade; 'p4 diff2' and 'p4 describe' require a p4d server upgrade. 'p4 resolve' rquires both. (Bug #879, #1671, #1932). Patch-friendly output - #35143 ** 'p4 diff2 -u', which produces more patch-friendly output, is now supported. It has long been present but undocumented. (Bug #380). TEMPOBJ FILETYPE REDUX - #36061 ** The 'tempobj' filetype, which stores only the head revision of the file (to conserve space), has been reimplemented to remove some of the serious problems associated with using this filetype. It is now safe to use. Previously, the server knew there were multiple revisions but they all shared the same text. This created problems with 'p4 submit' (aborted submits would update the text anyhow), 'p4 verify' (the revision fingerprint would change), 'p4 sync' (syncing a non-head rev would still give the head rev's text), and 'p4 obliterate' (obliterating the non head rev would remove the head rev's text). Now the server associates text with each revision (just as with non-tempobj files) and goes through the extra step of purging the previous revision during 'p4 submit'. 'p4 filelog' will display non-head revisions as 'purged' and they are treated like a deleted revision: 'p4 sync' will remove the file on the client and 'p4 verify' will ignore them. With this change, the filetype modifier "+S" changes from a storage type (uncompressed binary with only the head rev stored) to a storage modifier (purge non-head revs). Any type of file (text, binary, compressed) may now take on the "+S" modifier. The filetype modifier "+M", which previously indicated compressed binary with only the head rev stored, has been supplanted by +S's new meaning. This table might make it clearer: keyword pre-2002.2 2002.2 -------- ---------- ----------- tempobj binary+Sw binary+FSw xtempobj binary+Swx binary+FSwx ctempobj binary+Mw binary+Sw +F = uncompressed +S = binary head-rev only (pre-2002.2) +S = purge non-head-revs (2002.2) +M = compressed binary head-rev only (pre-2002.2) +w = client file always writable (all tempobjs) +x = executable bit set on client The 2002.2 server will upgrade existing tempobj files to the new. This requires a database upgrade with 'p4d -xu'. (Bug #1025, #2642, #3888, #7775). NEW PROTECTION LEVEL FOR SEMI-SUPER USERS - #35832 ** A new 'p4 protect' level 'admin' has been introduced below 'super' to permit many administrative commands without granting total superuser access. The commands now requiring only 'admin' access are: p4 branch -f p4 change -f p4 client -f p4 job -f p4 jobspec p4 label -f p4 obliterate p4 typemap p4 unlock -f p4 verify The commands still requiring 'super' access are: p4 admin p4 counter -f p4 depot p4 group p4 jobs -R p4 passwd user p4 protect p4 triggers p4 user -f (Bug #3037, #1306, #2842, #3520, #5004. This change only tangentially addresses some of these bugs.) Minor new functionality in 2002.2 #36081 ** "p4 resolve" now writes its messages through the methods of the ClientUser class rather than directly to stdout to allow API users to capture and parse the output. This change is only relevant to API users. (Bug #6881.) #35972 ** 'p4 resolve' now recognizes if the resulting file has been edited to match either 'yours', 'theirs', or the automatically merged result, and changes its default suggested action appropriately. In this way, if an external merge tool produces exactly 'theirs' then 'p4 resolve' can still arrange for a lazy copy in the server. #35391 ** 'p4 describe' of a pending changelist now includes the affected files. This fixes our oldest open bug. (Bug #13, #4974). #35390 ** The new option 'p4 revert -n' just displays which files would be reverted without actually reverting them. #35368 ** Long running operations that have been cancelled by the client can now be detected and terminated in the server. This feature may not be available on all platforms. (Bug #409). #35145 ** The new options 'p4 files -a' and 'p4 print -a' display all revisions in a revision range, rather than just the highest revision. #35114 ** 'p4 filelog' has an additional option "-t" when specified will display the time as well as the date. (Bug #553). #35063 * Adding support for Mac OS Roman character set in i18n mode. To use, set P4CHARSET to "macosroman". #34972 ** p4 info now displays the offset from UTC of the server timezone numerically and with a symbol if the symbol supplied from the OS is ASCII. (Bug #9359). Bugs fixed since 2002.2/39491 (first release). #43923 ** The proxy's RCS based cache files could be corrupted if concurrent updates to that RCS file occurred due to multiple clients requesting a revision from that file. Fixed. Related, the executable bit will no longer be set on RCS files. Also related, RCS anomolies if one client is used concurrently by multiple processes to submit the same file. (Bug #6054 & #10512) #42711 ** A 3 way merge during a resolve of large files (>20000 lines) could cause the server to crash, this has been fixed. (Bug #10835). #42453 ** Prior to 2002.2 there was a bug that under certain conditions allowed a lazy copy of a tempobj archive file. In 2002.2 the new tempobj implementation purges old copies (,t) files replacing them with the appropriate base type. A 2002.2 user can run into a problem if they try and access one of the branched files that have (since 2002.2 upgrade) had the base file for the lazy copy purged. This fix prevents old tempobj files (,t) from being removed during a submit although they will still be marked as "purged" in the rev table. When trying to access a file that had been purged as previously stated the user would receive an error something like this: Librarian checkout depot/branch/foo.c failed. open for read: depot/branch/foo.c,t: The system cannot find the file specified Even if this fix has been applied it is still possible to get the above error message if the base file was purged before this version was installed (in a previous 2002.2 release). If this happens the file can be manually fixed up, for help on this please contact technical support. (Bug #10581). #41819 ** Due to the sometimes significant overhead of indirect integration, 'p4 integ -i' has been reverted to its previous use of just allowing baseless merges. A new option 'p4 integ -I' is required to use the new 2002.2 feature to find intermediate files when determining a base. (Bug #10587). #41516 ** 'p4 print -o' through the proxy might fail silently depending on network timing. Fixed. (Bugs #10491, #10511, #10574) #41173 ** 'p4 verify' could crash the server if it ran out of available memory. (Bug #10468). #41169 ** Long running operations that have been cancelled by clients running on NT were not detected on an NT server. Fixed (Bug #10465). #41147 ** 'p4 sync' through the proxy was not honoring a client's 'allwrite' option if files were delivered from the proxy. Fixed. (Bug #10398) #40318 * 'p4 revert' of a file with the client option "modTime" set under certain circumstances could lead to the error: ("utime: filepath: Access is denied.") This problem has been fixed. (Bug #10202). #40313 * 'p4 resolve' when prompted for a "confirm accept (y/n)" would incorrectly throw up two messages if the user answered in the negative "n". This would be very confusing and has been fixed (Bug #10212). #40216 ** Certain p4 commands with a "filepath@label" argument could cause a unnecessary scan of the label table. This would occur if the filepath supplied did not contain any file revisions. This problem has been fixed. (Bug #10204). #40122 ** Trying to integrate from the new tempobj type would result in the incorrect warning message "can't branch without -d flag". This problem has been fixed. (Bug #10166). #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. Bugs fixed in 2002.2 #38452 ** p4d sometimes core dumped on shutdown on hpux11 PA-RISC machines. This has been fixed. (Bug #9641) #38559 * The "share" client line-end option has been extended to include support for Mac files that use linefeeds as their line terminator. (Bug #9068). #37237 ** p4d -xv and p4d -xr did not recongnize or correct btree corruption where a btree page's first few bytes had been corrupted. This case should now be handled properly. (Bug #9501). #37746 ** 'p4 integrate -i' was "giving credit" for indirect integrations that hadn't necessarily affected the target file, suppressing proper integrations from happening. This has been fixed. (Bug #9573). #37236 * Client programs running in timezones east of GMT sometimes miscalculated their GMT offset, resulting in incorrect modtimes on submitted and sync files. This has been corrected. This fix does not attempt to fix the modtimes of files previously submitted with the wrong modtime. (Bug #9503). #36747 * 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. This problem would only become evident if you also operated with other, non-OSF clients. The OSF clients now set file modtimes correctly. (Bug #9212). #36584 * On Cygwin the p4 client program would exit (quickly) if the 'rmdir' client option was set when a file was removed from the current directory (either through 'p4 sync' or 'p4 delete'). This has been corrected with an internal workaround. (Bug #7478, #7543). #36150 * 'p4 revert -a' wasn't resetting the modification time for a file when the client had the option 'modtime' set. This has been fixed. (Bug #8978). #35946 ** 'p4 obliterate -z' without the '-y' (make the changes) now only reports what it would do. It used say it was in report mode, but then actually undo lazy copies. Now '-y' is required for 'p4 obliterate -z' to take effect. (Bug #3613). #35869 ** 'p4 diff2 @label1 @label2' would issue a bogus error message ("RelateMap has empty maps!"). This has been fixed. (Bug #1382). #35829 ** Some server errors that occur before protocol initialization (like being unable to open the database) could result in a bogus error message ("Required parameter 'func' not set!") sent to the client. This has been fixed. (Bug #8110). #35799 ** Using p4d -xi to enable I18N mode would sometimes incorrectly fail reporting non-UTF8 data in either the db.job or db.change table. This has been corrected. (Bug #9011). #35738 ** 'p4 changes -s pending' is not compatible with a file argument as it will always return no data (since only submitted change information is available in the rev table). Supplying a file argument has now been disallowed to avoid any confusion. (Bug #371). #35403 ** 'p4 job -f' would not allow an update of read-only "once" fields. This has been corrected. (Bug #5938, #8111). #35274 ** To speed p4win, performance of 'p4 changes -m1 filepath' has been specially optimized. This only speeds this exact command: filepaths including @client and @label will not be affected by this change. (Bug #7306). #34362 ** The internal support for optimizing p4win's performance against large servers (see #29329 below) sometimes didn't work with the case-insensitive (Windows) Perforce server. This has been corrected. (Bug #8404). #34284 ** 'p4 edit ' where the number of files is greater than the value set for "maxscanrows" would result in an incorrect error message being returned. This has been corrected. (Bug #7837). #34069 ** A new error message indicates attempted access by a user not enabled at all via 'p4 protect'. Previously, it was not possible to tell if a user had no access at all or just no access for the requested command. #33552 ** 'p4 filelog @