Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Remote depots and multi-server development

Remote depots are a legacy approach for code drops, the sharing of code between separate software organizations as read-only archive files Versioned files that users submitted to a depot. without access to metadata Information that P4 Server maintains, such as who created file revisions in the depot, whether the file is a 'lazy copy,, the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the 'archive files' that users submit from their client workspace into the depot.. 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.

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, such as commit-edge.

Remote depots appear on the local P4 Server in the same way local depots do. The local P4 Server communicates with the remote P4 Server to access a subset of its files.

A "remote depot" is a depot on your P4 Server of type `remote`. It acts as a pointer to a depot of type `local` or `stream` that 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.

Although the remote depots feature is still supported, alternatives for code drops that are less likely to cause performance problems are Distributed versioning (DVCS) and Distribution Server.

Remote depots can cause significant performance issues for commands that attempt to access all depots in your repository. For example, a command like

p4 sizes -sh @=12345

queries all depots, including remote depots, and the access might be unacceptably slow.

Similarly, if you have another P4 Server with a remote depot pointing at one of your depots, access by the remote user can cause locking delays. For example, a remote access can lock out a submit, which, in turn, can lock out other commands for much longer than expected.

If you are using this legacy feature, ensure you do so in a secure manner. To learn more, see Restrict access to remote depots.

Your search for returned results