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