Major Enhancements
Graph Depot support * **
A collection of new features provide direct support for git repositories and git workflows using the p4d server. In addition to the new server features (outlined below), there is a new server component, called the Connector, that is separately installable as needed, and provides services which are broadly similar to those provided by Perforce proxy and replica servers.
The new features you should be aware of include:
- server data model support
- authentication and authorization enhancements
- p4 command line access to git versioned files
- new triggers
To learn more about the Connector component, please read its release notes and documentation. Below is a broad overview of the new p4d support; for details, please read the server documentation.
Server data model support:
A single p4d server new supports storage of versioned files using either the classic Perforce data model, or using the git data model. The data model to use is specified on a depot-by-depot basis: a depot of type "graph" is used to store one or more git repositories. The server automatically creates a graph depot named 'repo'; you may create additional graph depots using the 'p4 depot' command.
git repositories are named using a hierachical naming scheme of the format: //depot/repo/path/name, using the new 'p4 repo' command.
Authentication and authorization enhancements:
git users accessing the Perforce server must be properly authenticated and authorized. When using the HTTPS protocol, git users are prompted for their Perforce username and password as necessary when they perform clone, push, or pull commands. When using the SSH protocol, git users authenticate using public key encryption; the appropriate public key for each user should be recorded in the server using the new 'p4 pubkey' command.
Access control for git repositories uses a new set of permissions, defined with the 'p4 grant-permission' command. The related revoke-permission, check-permission, and show-permission commands are also useful for defining and maintaining repository access control rules.
Command line access to git versioned files:
A client workspace can be configured to access git versioned files by mapping paths from repos within graph type depots; non-graph depot paths may also be mapped in the same client view.
The 'p4 sync' command will then sync the specified version of the specified files from one or more git repositories and other depots to the corresponding location in your client's filesystem. Similarly the 'p4 have', 'p4 files', 'p4 dirs' and 'p4 fstat' commands will also report on the metadata from git repositories as well as other depots. Not all flags for these commands are applicable for graph.
New triggers:
Several new trigger types are available to allow administrators to define custom policies for access to git repository data, and to support advanced workflows such as initiating build/test automation activities upon the completion of a git push command.
Licensing:
The default maximum repos allowed for a server is 10, to increase this limit contact Perforce Sales at [email protected].
(For more information see 'p4 help --depot-type=graph').
#1434004 * ** *** TCP connection changes to improve performance over long latency connections. Significantly more information may be in transport now and clients and intermediate processes need to handle more data in a timely manner. This new behavior can be disabled in clients, proxies, brokers and the server with the configurable net.autotune which defaults to 1 (enabled) and can be set to 0 to disable. Clients can set this via "p4 set" or P4CONFIG files and servers can set this via "p4 configure." On Windows based platforms, send buffer sizes are not autotuned but still are manually configuable with net.tcpsize.
#1425396 (Bug #88065) ** Binary fields in journal records will now be written in base64 instead of hex with a few exceptions. Binary objects of length 1 will still be written in hex and some md5 digest fields will still be hex.
Minor Enhancements
#1487961 (Bug #90210) ** New server option '--daemonsafe' is like '-d' and forks the 'p4d' into the background, but also closes the stdio files.
#1486890 (Bug #88954) ** The utf8 file type was not handled properly by clients older than 2015.2 and the p4 java api. The server now attempts to work with these older clients by handling the byte-order-mark in the server and having the server produce digests which these older clients will expect. Operation with utf8 files and these old client will skip proxy caching also. These older clients and utf8 filetype will assume the BOM is present while clients 2015.2 can adapt to a BOM being present or not.
#1459677 (Bug #89065) ** The 'p4 verify -v' command now supports updates to files which have been branched into one or more active task streams. Please see 'p4 help verify' for more details about this scenario.
#1458367 (Bug #37069, #89070) ** The 'p4 move -r' command allows users to rename or change the location of files in the depot without opening them for edit first.
#1457332 (Bug #89008) ** The 'p4 remotes' command now accepts the '-u user' flag.
#1453638 (Bug #84442) ** The --remote-user flag may be specified on the fetch, push, and login commands, overriding the RemoteUser field in the remote spec for this command.
#1450711 (Bug #88643) ** A restriction on using the 'p4 renameuser' command in a Commit-Edge configuration has been removed: it is now safe to use the command to rename a user who owns workspaces and/or labels on one or more Edge Servers. Note that unloaded workspaces are still not processed by the command, no matter which server those workspaces reside on.
#1448666 (Bug #63670) ** A new type of structured server log audit record format which includes the revision's size in bytes is now available. To specify the logging of these alternate audit records, change the name of your audit log from 'audit.csv' to 'auditsize.csv'.
#1442507 (Bug #69777) ** Two new security levels have been introduced to enforce stricter intermediary checking. Setting the security configurable to 5 to higher will require each intermediary to have a valid authenticated service user. Setting the security configurable to 6 to higher will require each intermediary to have a valid server spec, where the service user must match the user named in the spec's 'User' field. The server spec will be found by matching the intermediary's P4PORT with a value in the spec's 'AllowedAddresses' field. For example, if connecting to a proxy on 10.0.0.100:1667, a server spec with this IP address and port number in the 'AllowedAddresses' field must exist and must have the proxy's service user named in the 'User' field. Errors relating to configuration of intermediaries will be logged to the 'route.csv' logfile, if enabled.
#1439069 (Bug #81269) ** When specifying file paths you can now use the change identity from the submitted change spec instead of the actual change number. So, for example given a change submitted with an identity: 'p4 sync //depot/...@30E7C829-08C504-4109-89AA-904D0C2194B8'
#1424268 (Bug #88017) ** The template.label configurable introduced by change 656580 now also applies to a label created via the 'p4 tag' command.
#1526517 (Bug #90686) ** Increase receive buffer sizes for the Perforce API to 1 megabyte which shows substantial performance improvement for several wide area network operations and prevents network hangs in some cases. Old value was 32k. Can be adjusted with net.rcvbufsize
Bug Fixes
#1505154 (Bug #90088) ** For a specific use case, a branch resolve is scheduled instead of a move resolve. This is fixed by backing out change
#1422325. #1502778 (Bug #89674) ** Obliterating files from a task stream that is no longer protected because it has been unloaded can cause revision inconsistency after being reloaded.
#1498792 (Bug #86088) ** Using 'p4 switch' between task streams and non-task can fail if a previous manual switch was done with 'p4 client -s' without subsequently calling 'p4 sync'.
#1489051 (Bug #2170) ** Submitting a file with the same name as an existing depot directory path (or vice versa) will now be rejected.
#1483947 (Bug #89040) * 'p4 print -o <a filename in the os temp directory>' will now work even if a P4CLIENTPATH is set or the DVCS P4INITROOT is set. This is a new exception to the P4CLIENTPATH feature.
#1481077, #1481305, #1483342 (Bugs #89051, #90160) * ** *** SSL connections now allow use of TLSv1.1 and TLSv1.2 in addition to the existing support for TLSv1.0. Clients and servers will choose the highest TLS version supported by both ends of the connection; thus old clients and old servers will always use TLSv1.0, and by default new clients connecting to new servers will use TLSv1.2.
Two new configurables are provided to restrict the allowed TLS versions when a new client connnects to a new server: ssl.tls.version.min [default=10] ssl.tls.version.max [default=12] These default settings allow TLSv1.0, TLSv1.1, and TLSv1.2.
Each of these configurables can take one of the following values: 10 specifies TLSv1.0 11 specifies TLSv1.1 12 specifies TLSv1.2 ssl.tls.version.min specifies the lowest TLS version that will be accepted, and ssl.tls.version.max specifies the highest TLS version that will be accepted.
Changes to these configurables on a server will not take effect until the server is restarted.
Thus, to force use of a new client, the server can set ssl.tls.version.min=11 (or 12) because old clients support only TLSv1.0.
To force the use of TLSv1.1, set ssl.tls.version.min=11 ssl.tls.version.max=11
To force the use of TLSv1.2, set ssl.tls.version.min=12 ssl.tls.version.max=12
To allow TLSv1.1 or TLSv1.2 but exclude TLSv1.0, set ssl.tls.version.min=11 ssl.tls.version.max=12
These configurables are designed to allow the server to restrict the set of allowed TLS protocol versions, but they can be used by clients as well; this is probably useful mostly for testing, although it can be use to prevent connecting to potentially vulnerable servers. When used by a client these configurables specify the lowest and highest TLS versions that will be offered.
Values of either configurable outside of the legal range will be treated as if they were pinned to the nearest end of the range. Thus values below 10 will be treated as 10; values above 12 will be treated as 12.
Be careful not to set ssl.tls.version.min > ssl.tls.version.max because then no clients will be able to connect. In this case you will need to change these settings on the command line, e.g.: p4d -c"set ssl.tls.version.min=10" p4d -c"set ssl.tls.version.max=12" and then restart the server.
Note that if there are no allowed TLS versions common to the client and the server, or if the server is not using SSL, then the client will get an error similar to this:
Perforce client error: SSL connect to ssl:host:1666 failed (Connection reset by peer). Remove SSL protocol prefix from P4PORT or fix the TLS settings.
If the client or server does not offer any protocol versions (eg, because the client set ssl.tls.version.min > ssl.tls.version.max) then the client will get an error similar to this:
Perforce client error: SSL protocol: error:14077102:SSL routines: SSL23_GET_SERVER_HELLO:unsupported protocol:
There are only two lines in this error message; the actual error has the "SSL protocol:" line and the "GET_SERVER_HELLO" line on a single line, but they are split here for readability.
#1480537 ** 'p4 protects -m' could incorrectly report a max permission of 'owner' (owner is not an access permission).
#1480400 (Bug #89648, #89890) ** The db.sendq entries for a failed parallel sync are now immediately removed from db.sendq.
#1479216 (Bug #89781) ** 'p4 depot -f' would allow changing the depot type of a depot that is not empty. This has been fixed.
#1475982 (Bug #89723) ** The rpl >= 2 condition for reporting replication tracking metrics has been removed. The replication tracking metrics will now be reported when the applicable tracking thresholds have been exceeded.
#1473097 (Bug #89657) ** 'p4d -xx' could incorrectly declare "db.workingx/db.revsh inconsistencies found," and incorrectly generate jnl.fix records, in some situations where multiple shelves existed for the same files.
#1471650 (Bug #89336) ** 'p4 add ...' could generate many "Error object passed to database" errors and fail to terminate when MaxScanRows or MaxLockTime has been reached. This could also happen with 'p4 reconcile' or 'p4 status'. This behavior has been fixed.
#1469144 (Bug #89527) ** A 'p4 shelve' command which needed to retry its change spec edit operation due to a spec validation error no longer fails with "No files to shelve."
#1467328 (Bug #87271) ** 'p4 clients -S //stream/name' now respects the case-sensitivity configuration of the server.
#1466515 (Bug #81281) ** Replica pull threads which receive error messages from their master server will now log those error messages into any replica structured server logs which record error events.
#1465792 (Bug #16821, #89204) * ** The configurable 'filesys.checklinks' may fail to prevent files from being added when files are symlinks to directories. This has been fixed. Also, this configurable is now honored for 'p4 reconcile' when detecting files to be added.
#1464985 (Bug #89311) ** The fetch/push/unzip commands might incorrectly declare a file conflict for a file which was moved multiple times, to different destinations, during its history.
#1463567 (Bug #86424) ** Edge Servers might halt replicating if an obliterate command was run concurrently with a very large populate or submit command.
#1460946 (Bug #88999) ** The 'p4 export' command now includes any @dl@ or @pk@ journal records as part of the journal data export.
#1458557 (Bug #89052) ** A forwarding replica with lbr.replication=shared will no longer attempt to update the (shared) archive area during the file transfer phase of a forwarded 'p4 submit'. The cache-on-submit behavior is still present for forwarding replicas with lbr.replication set to either readonly or cache.
#1455848 (Bug #88980) ** In replica chaining configurations, replicas which were not directly connected to the master server were not processing archive deletion operations arising from operations such as submission of a binary+S file, deletion of a shelf, obliteration, archive depot operations or retype +l commands.
#1449343 (Bug #85596) ** The 'logparse' command no longer attempts to open an erroneous file when the structured log's configurable includes a path.
#1447186 (Bug #84067) ** The number of fsync() calls for 'rdb.lbr' executed by a replica server fetching graph depot packfiles has been reduced. In some environments, this can improve the performance of fetching graph depot packfiles.
#1446257 (Bug #84067) ** The number of fsync() calls for 'rdb.lbr' executed by a replica server fetching file content on demand has been reduced. In some environments, this can improve the performance of fetching file content on demand.
#1445640 (Bug #88728) ** The configurables rpl.awaitjnl.count and rpl.awaitjnl.interval were inadvertently swapped; they are now corrected.
#1440527 (Bug #88441) ** 'p4 verify -S //filepath/...@=<shelved changelist>' would scan the db.revsh table.
#1439920 (Bug #88350) ** If an error was encountered when opening an archive file for write on the commit server during an edge submit, the commit server might crash. The edge submit now reports the error encountered and fails gracefully.
#1432576 (Bug #88205) ** The 'rdb.lbr' tracking metrics are now aggregated to reflect larger operations. Since the aggregated metrics might now more readily exceed a tracking threshold, the 'rdb.lbr' tracking output might be more likely to be written to the server log when the 'rpl' configurable is set to a value of two or greater.
#1431630 (Bug #88189) ** The 'rdb.lbr' tracking metrics are now correctly reported for the edge server's metadata pull thread when the 'rpl' configurable is set to a value of two or greater.
#1425567 (Bug #88085) ** The number of fsync() calls for 'rdb.lbr' executed by the commit server for coordinating the file content fetched during a parallel submit though an edge server has been reduced. In some environments, this can improve the performance of parallel submit through an edge server.
#1424177 (Bugs #26502, #51997, #59889, #69919, #88018) ** The server now rejects client and branch views that end with "...." on one side and "..." on the other.
#1419208 (Bug #67640) ** A 'p4 sync' command issued to a forwarding replica of a forwarding replica will now deliver file content from the outermost forwarding replica in the chain, rather than the innermost. However, it is now illegal to deploy a proxy to a forwarding replica. If you had such a deployment, you will need to either (a) reconfigure that proxy to point directly to the master, (b) replace that proxy with a forwarding replica, or (c) remove that proxy entirely.