What’s new in this guide
This section provides a summary with links to topics in this Guide. For a complete list of what's new in this release, see the Release Notes.
2020.1 release
-
The storage upgrade process is now visible through the
p4 monitor
command. See p4 monitor in Helix Core P4 Command Reference. - A heartbeat-related trigger or extension can be part of a solution to monitor whether a server is responsive. See Triggering on heartbeat (server responsiveness)
- TLS 1.3 is now supported, but TLS 1.2 remains the default. See ssl.tls.version.max in the Helix Core P4 Command Reference.
- A unique command identifier is now visible through structured logging for schema version
50
. See Logging and structured log files and the Support Knowledgebase article on Structured Server Logs. -
Global labels can now be updated from edge servers using either
p4 tag -g
orp4 labelsync -g
. See p4 tag and p4 labelsync in Helix Core P4 Command Reference. - The host field in the protections table now allows multiple IP addresses or CIDR matchers to be specified on a single line with a comma-separated list. See p4 protect in Helix Core P4 Command Reference.
-
The sequence numbers used in
db.protect
are no longer contiguous. This allows new lines to be added without rewriting the whole table. - Standard users can now view the storage record table.
- A new configurable has been added to suppress the generation of digests during a storage upgrade from versions prior to 2019.1. See lbr.storage.skipkeyed in Helix Core P4 Command Reference.
- The scan of the protections table at command start is now lockless. This means that updates to the protections table on busy servers will experience less lock contention.
Documentation-related
- Helix Core Server Administrator Guide is now a single volume instead of being split between "Fundamentals" and "Multi-site Deployment". What was previously "Helix Core Server Administrator Guide: Multi-Site Deployment" is included here under Deployment architecture.
- For clarity, "multi-server environment" means what was formerly called "distributed environment" and "distributed" is primarily associated with Using Helix Core Server for Distributed Versioning (DVCS).
- This manual now explains how to get the latest patch release. See Patching the server.
2019.2 release
Upgrading
The 2019.2 upgrade steps are significantly different from any prior release. See Upgrading the server.
Improvements to structured logging
Structured logging has a new format so it can be more helpful for the analysis of performance. See Logging and structured log files.
failed-over trigger
A new type of trigger, failed-over, can run when a standby server becomes the new master. See Triggering on failed-over.
2019.1 release
-
Carefully follow the steps in the chapter on Upgrading the server because they are different from those of upgrades to versions prior to 2019.1.
- Extensions, a new technology that is similar to Triggers, but with advantages and additional capabilities. See Triggers and Extensions.
- When the server is busy with the maximum number of commands and therefore blocking standard users,the super and operator User types can still issue a subset of commands. See Limiting simultaneous connections > Too many commands.
- You can save disk space when creating an archive depot by using the option that includes lazy copies, which are small references to the location of potentially large files. A new database table, db.storage, replaces the db.archmap table to provide a link count for archive files on the server. This tracking reduces the complexity of identifying lazy-copies, allowing +Sn files to be lazy copied by reference instead of being duplicated with their full contents. See p4 archive -z inHelix Core P4 Command Reference.
- Faster verification of archives (depot files) with p4 verify
- such verification can also be done with a new command, p4 storage -v
- Display, verify, or update physical archive storage with the new command, p4 storage
- Faster p4 obliterate
- The procedure for setting up a high availability server for Failover has changed. See A high availability standby within an existing installation should not be initially deployed as mandatory.
- Note that Helix Core P4 Command Reference indicates that the net.autotune configurable is on by default.
- (Doc-only change: The How protections are implemented topic has been expanded.)
-
End-users can benefit from the Background archive transfer for edge server submits.
- Edge-to-edge chaining: an edge server can be configured to connect to another edge server without needing to sync from a remote commit server. See also "Commit-edge" in Deployment architecture and Filtering metadata during replication or edge-to-edge chaining
2018.2 release
- Failover to a new master server is now an easier process
-
Installation support for SUSE Linux Enterprise Server - see Linux package-based installation
- Clarification on when trigger-based authentication can fall back to a password request: Single sign-on and auth-check-sso triggers
-
If you want to write a trigger that requires users to log in with additional security, see Triggering for multi-factor authentication (MFA)
- Multi-factor authentication (MFA) is the current name for a feature that was originally introduced as second-factor authentication (2fa)
- Helix SAML is a new feature for authentication
2018.1 patch
If you want to write a trigger that requires users to log in with additional security, see Triggering for multi-factor authentication (MFA)
Installation support for SUSE Linux Enterprise Server 11 and 12 - see Linux package-based installation
2018.1 release
You no longer need to use the -z
option to restore a compressed checkpoint or journal. This allows the chaining of files for the restore. For example:
p4d -r . -jr checkpoint.42.gz journal.42 journal.43 journal
See the topic named "Database corruption, versioned files unaffected", which has a Note about Version 2018.1
See graph-push-reference triggers at Triggering with depots of type graph
A new structured log, ldapsync.csv, has been added to record the activity of p4 ldapsync. See Enable and configure structured logging.
2017.2 release
Triggers for external file transfer
See Triggers for external file transfer
Server background tasks
See p4 bgtask in the Command Reference
Parallel threads
p4 shelve now accepts the --parallel
flag to specify that multiple files should be transferred in parallel, using independent network connections from automatically-invoked child processes. In addition, new configurables net.parallel.shelve.*
allow p4 shelve to automatically use parallel threads to transfer files. Please see p4 help shelve
and p4 help configurables
for complete information.
The net.parallel.sync.svrthreads configurable reduces the number of parallel transmit threads used by sync commands when the total number of "user-transmit" threads (from all commands) running concurrently in the server would exceed the value of this configurable. Server monitoring must be enabled for this new configurable to take effect.
Complete replication for graph depot archives
Edge servers support syncing file content from graph depots. Replication supports graph depots that contain pack files, loose files, or a mixture of the pack files and loose files.
New content can be pushed by using the Git Connector or committed with p4 submit or p4 merge.
For information about depots of type graph, see: