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, consider a different Deployment architecture.

If, however, your organization regularly imports or exports material from other organizations, you might want to consider using the remote depot functionality of Helix Server to streamline your code drop procedures.

Remote depots appear on the local Helix Server in the same way local depots do, but with some restrictions. See Restrictions on remote depots.

The local Helix Server communicates with the remote Helix 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 installations of Helix Server to integrate changes between those 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 or stream 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 which 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 Restrict access to remote depots for security requirements.

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