Preface

This book, Helix Versioning Engine Administrator Guide: Multi-Site Deployment (previously titled Distributing Perforce), is a guide intended for administrators responsible for installing, configuring, and maintaining multiple interconnected or replicated Perforce services. Administrators of sites that require only one instance of the Perforce service will likely find the Helix Versioning Engine Administrator Guide: Fundamentals sufficient.

This guide assumes familiarity with the material in the Helix Versioning Engine Administrator Guide: Fundamentals.

About this manual

This manual includes the following chapters:

Chapter	Contents
“Introduction to Federated Services”	Describes the different types of Perforce servers and explains how you combine these to solve usability and performance issues. In addition, this chapter discusses the issues that affect service federation independently of the particular type of service used: issues like user authentication and communication among federated services. Subsequent chapters in this book describe each type of service in detail.
“Perforce Replication”	Explains how you work with server replicates to provide warm standby servers, to reduce load and downtime on the primary server, to provide support for build farms, or to forward write requests to a central server.
“Commit-edge Architecture”	Describes commit-edge architecture, which addresses the needs of geographically distributed work groups and offers significant performance advantages. Explains how you set up a commit-edge configuration, how you migrate from an existing installation, how you manage this configuration, how you use commit/edge triggers, and how you plan for disaster recovery.
“The Perforce Broker”	Explains how yo use the Perforce broker to implement local policies in your Perforce environment by redirecting server requests and by mediating between the client and other servers in your federated environment. Provides information about how you install, configure, and run the broker.
“Perforce Proxy”	Explains how you use a Perforce proxy to improve performance in a federated environment. Describes how you install and configure the proxy and how you use it to maximize performance.
Perforce Server (p4d) Reference	Provides reference information about the syntax and options of the p4d command used to create and configure a Perforce server.

What's new in this guide for the 2016.1 update

This section provides a list of changes to this guide for the Perforce Server 2016.1 update release. For a list of all new functionality and major bug fixes in Perforce Server 2016.1, see the Perforce Server 2016.1 Release Notes.

Major changes

New -c option to p4 server command provides a short cut to configuring an edge or commit server: See Shortcuts to configuring the server for more information.

Updates and corrections

Setting P4AUTH for a replica

You must use the p4 configure set command to set P4AUTH for a replica.

Clarification of remote user

There is no remote type user; there is a special user named remote that is used to define protections for a remote depot.

Clarification about state file

Upon restart, the replica reads the state file and picks up where it left off; do not alter this file or its contents.

When the state file is written, a temporary file is used and moved into place, which should preserve the existing state file if something goes wrong when updating it. If the state file should be empty or missing, the replica server will refetch from the start of its last used journal position.

Staggering checkpoints

For commit servers with no local users, edge servers could take significantly longer to checkpoint than the commit server. You might want to use a different checkpoint schedule for edge servers than commit servers. If you use several edge servers for one commit server, you should stagger the edge-checkpoints so they do not all occur at once and bring the system to a stop. Journal rotations for edge servers could be scheduled at the same time as journal rotations for commit servers.

Clarification of broker REDIRECT action

This redirects the command to a different (alternate) replica server. An altserver is required. A message for the user is optional. To implement this action, the broker makes a new connection to the alternate server and routes all messages from the client to the alternate server rather than to the original server. This is unlike HTTP redirection where the client is requested to make its own direct connection to an alternate web server

You can specify more than one value for debug level

For more information, see Global settings.

Helix documentation

The following table lists and describes key documents for Helix users, developers, and administrators. For complete information see the following:

http://www.perforce.com/documentation

For specific information about…	See this documentation…
Introduction to version control concepts and workflows; Helix architecture, and related products.	Introducing Helix
Using the command-line interface to perform software version management, working with Helix streams, jobs, reporting, scripting, and more.	Helix Versioning Engine User Guide
Basic workflows using the P4V, the cross-platform Helix desktop client.	P4V User Guide
Working with personal and shared servers and understanding the distributed versioning features of the Helix Versioning engine.	Using Helix for Distributed Versioning
p4 command line (reference).	P4 Command Reference, p4 help
Installing and administering the Helix versioning engine, including user management, and security settings.	Helix Versioning Engine Administrator Guide: Fundamentals
Installing and configuring Helix servers (proxies, replicas, and edge servers) in a distributed environment.	Helix Versioning Engine Administrator Guide: Multi-site Deployment
Helix plug-ins and integrations.	IDEs: Using IDE Plug-ins Defect trackers: Defect Tracking Gateway Guide Others: online help from the Perforce menu or web site
Developing custom Helix applications using the Helix C/C++ API.	C/C++ API User Guide
Working with Helix in Ruby, Perl, Python, and PHP.	APIs for Scripting

Syntax conventions

Helix documentation uses the following syntax conventions to describe command line syntax.

Notation	Meaning
`literal`	Monospace font indicates a word or other notation that must be used in the command exactly as shown.
`italics`	Italics indicate a parameter for which you must supply specific information. For example, for a `serverid` parameter, you must supply the id of the server.
[`-f`]	Square brackets indicate that the enclosed elements are optional. Omit the brackets when you compose the command. Elements that are not bracketed are required.
…	Ellipses (…) indicate that the preceding element can be repeated as often as needed.
`element1` \| `element2`	A vertical bar ( \| ) indicates that either `element1` or `element2` is required.

Please give us feedback

We are interested in receiving opinions on this manual from our users. In particular, we'd like to hear from users who have never used Perforce before. Does this guide teach the topic well? Please let us know what you think; we can be reached at [email protected].

If you need assistance, or wish to provide feedback about any of our products, contact [email protected].

Helix Versioning Engine Administrator Guide: Multi-site Deployment (2016.1)