Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Distributed Versioning Documentation | 2025.1

# Centralized and distributed architecture

P4 Overview mentioned that version control systems can implement either a centralized model or a distributed model. P4 Server supports both of these models, as well as configurations that are a hybrid of the two.

In a centralized model, users interact directly with a shared server, checking out files, working in those files, and then checking them back in to the shared server:

The client is a program that users interact with, such as the P4 Server command line client, P4V, and (Undefined variable: Perforce.P4Connect). Clients, in turn, interact with servers, which can also interact with each other.

Some clients might access a subset of the files stored on the shared server, while other clients might access all the files stored on the server.

## Distributed model: server-to-server versus personal server

You can use the distributed model for server-to-server purposes or as a personal server.

### Server-to-server use cases

Some administrators find it convenient to use the P4 Distributed Model to move data between P4 Servers or share code between two P4 Servers.

To enable a use case such as this:

- Configure each P4 Server to allow the level of pushing and fetching you want. See the server.allowfetch and server.allowpush configurables in P4 CLI Reference.

- Create remote specifications containing the mappings of files between servers. See Distributed development using Fetch and Push in P4 Server Administration Documentation.

### Personal server

The typical personal server use case involves using p4 clone from a shared server to creates a user's own personal server. This allows that user to use p4 push and p4 fetch to synchronize changes between the shared server and the personal server.

The distributed model gives users access to a repository of archived files — and changes to those files — from a server running on their local machine. This means that the entire history of a file is contained on each user’s machine. A user can manage versioned content without interacting with any other P4 Server, also called P4 Server or `p4d`, or even connecting to a network. A user can also rewrite and revise history to discard unwanted intermediate changes. The distributed model allows users to work experimentally, to try out changes and branch new streams, without interfering with others' work, and without the need for a network connection.

The distributed model:

In the distributed model, a user can work on their individual server until they’re ready to copy content to a shared server, making the content available to other users.

Unlike other version control systems, such as Git, users can copy a subset of the shared server’s content to the server on their own machine, rather than copying the entire shared server repository.

In this model, users first submit changes to their personal server and then push changes to a shared server. A different user can then fetch those changes from the shared server to have a copy on their personal server.

Each client can submit changes to its respective personal server and then push changes to and fetch changes from the shared server. The distributed model with push and fetch of a subset of files:

The distributed model also supports a hybrid workflow that includes both centralized and distributed client-server relationships. This allows users both to share their work by connecting their individual server to a shared server, and to interact directly with a shared server. A hybrid configuration:

In addition, P4 Server distributed versioning allows synchronization of content across multiple offices or teams. You use the `p4 fetch` and `p4 push` commands if the servers are networked or the `p4 zip` and `p4 unzip` commands if they’re not. See "Managing Distributed Development" in P4 Server Administration Documentation.

Your search for returned results