What’s new in the Helix Core Server Administrator Guide

This section provides a summary with links to topics in this Helix Core Server Administrator Guide. For a complete list of what's new in this release, see the Release Notes.

2022.1 release

  • Failback after failover

  • Real-time monitoring to enhance administration: set the rt.monitorfile configurable and adjust the monitor level while commands are running. To identify commands that have been holding locks on tables for long periods and the commands that are waiting for those locks to be released, set the monitor configurable to 10 or 25.

  • Option to set the server.id of the proxy server. See General options > -xD [serverID] in Helix Proxy

  • p4 group has the optional Description: field, which might be useful if your company has a large number of group

  • Checkpointing options enhancements in Helix Core Server (p4d) Reference:

    • Checkpoint production is easier with the -P server-id and -R service options. See p4d [-z] [-R service | -P server-id] -jd file

    • Checkpoint recovery is easier with the -R service option. See p4d [-z] -R service -jr file

  • P4V administration:

For additional new features, see What’s new in the Helix Core Command-Line (P4) Reference.

2021.2 release

2021.1 release

Note

If you are licensed for Helix Core version 2021.1 patch 1 or greater, Helix4Git licensing is included at no extra charge.

2020.2 release

  • During upgrades to a new server version, the upgrade steps now execute in the background (applies to 2019.2 and later upgrade steps). This can improve server availability and replication performance during upgrades.

  •  Any new file being shelved that has the same content as an existing shelved file now refers to the existing archive file instead of creating a duplicate archive file.
    • To avoid overwriting the content of shelves that share archives, the archives of the new shelved files now have an additional numerical suffix. For example, 1.1.1.gz instead of 1.1.gz.
  • The Helix Proxy service can now be configured to use a different path for databases by either setting the P4PROOT environment variable or by using the -R proxy option. By default P4PROOT is the same as P4PCACHE, and both databases and archives will reside on the same path.

  • Enhancement of Background archive transfer for edge server submits: if the administrator has not enabled background submit, the -b option of p4 submit is ignored and standard submit behavior occurs.

  • Failover from a mandatory standby server when the master is not participating used to require specifying -s <serverID>. Now, failover for this scenario includes checking the ReplicatingFrom field of the standby server spec for the master's serverID when -s is not specified on the command line.

    • Part of the failover process involves stopping the journalcopy and pull threads. If the failover process fails, those threads needed to be restarted manually. Now any pull -L, pull -u, or journalcopy threads that were configured using startup.N configurables will automatically be restarted if the failover process did not succeed.
  • For your end-users of P4V 20.3 and later, you can set the maximum number of files to load into the Depot tree at any one time. See P4V.Performance.DirFetchSize in Performance-related P4V properties.

2020.1 release

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

2018.2 release

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: