Remote depots and multi-server development

Helix Server is designed to cope with the latencies of large networks and inherently supports users with client workspaces at remote sites. A single Helix Server installation is ready, out of the box, to support a shared development project, regardless of the geographic location of its contributors.

Partitioning joint development projects into separate Helix Server installations does not improve throughput, and usually only complicates administration. If your organization has developers in multiple sites working on the same body of code, it is better to set up a multi-server installation.

If, however, your organization regularly imports or exports material from other organizations, you might want to consider using Perforce’s remote depot functionality to streamline your code drop procedures.

When using remote depots, the user’s client application uses the Helix Server specified by the user’s P4PORT environment variable or equivalent setting as a means to access a second, remote, Helix Server. The local Helix Server communicates with the remote Helix Server server to access a subset of its files.

Remote depots are designed to support shared code, not shared development. They enable independent organizations with separate Perforce installations to integrate changes between Perforce installations. Briefly:

• A "remote depot" is a depot on your Helix Server of type remote. It acts as a pointer to a depot of type "local" that resides on a second Helix Server.
• A user of a remote depot is typically a build engineer or handoff administrator responsible for integrating software between separate organizations.
• Control over what files are available to a user of a remote depot resides with the administrator of the remote server, not the users of the local server.
• See Restricting access to remote depots for security requirements.

For an alternative option to share code, see Distributed development using Fetch and Push.