Remote depots and multi-server development
Helix Core Server is designed to cope with the latencies of large networks and inherently supports users with client workspaces at remote sites. A single Helix Core 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 Core 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 Core Server to streamline your code drop procedures.
Remote depots appear on the local Helix Core Server in the same way local depots do, but with some restrictions. See Restrictions on remote depots.
The local Helix Core Server communicates with the remote Helix Core 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 Core Server to integrate changes between those installations. Briefly:
- A "remote depot" is a depot on your
Helix Core Server
of type
remote. It acts as a pointer to a depot of typelocalorstreamthat resides on a second Helix Core 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.
