Centralized and distributed architecture

Helix Core Overview mentioned that version control systems can implement either a centralized model or a distributed model. Helix 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:

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 Helix Core Distributed Model to move data between Helix Core Servers or share code between two Helix Core Servers.

To enable a use case such as this:

• Configure each Helix Core Server to allow the level of pushing and fetching you want. See the server.allowfetch and server.allowpush configurables in Helix Core Command-Line (P4) Reference.

• Create remote specifications containing the mappings of files between servers. See Distributed development using Fetch and Push in Helix Core Server Administrator Guide.

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 Helix Core Server, also called Helix 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, Helix 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 Helix Core Server Administrator Guide.