p4 depot

Synopsis

Syntax

Description

• You'd like to have separate depots for separate projects stored on the same server.

• You want to access files on one Perforce server from another Perforce server.

In the latter case, referred to as the use of remote depots, the Perforce client's default Perforce server (i.e. the machine specified in P4PORT) acts as a proxy client to the remote Perforce server, so the client doesn't need to know where the files are actually stored.Remote depots are restricted to read-only access. Thus, a Perforce client program can't add, edit, delete, or integrate files that reside in the depots on the other servers. For more information about remote depots, see the Perforce User's Guide and the Perforce System Administrator's Guide.

To create or edit a depot, use p4 depot depotname and edit the fields in the form.

Form Fields

Field Name	Type	Description
Depot:	Read-Only	The depot name as provided in p4 depot depotname.
Owner:	Writable	The user who owns the depot. By default, this is the user who created the depot.
Description:	Writable	A short description of the depot's purpose. Optional.
Type:	Writable	local or remote. Local depots are writable; remote depots are proxies for depots residing on other servers, and cannot be written to.
Address:	Writable	If the Type: is local, the address should be the word subdir. If the Type: is remote, the address should be the P4PORT address of the remote server.
Map:	Writable	If the Type: is local, the map should be the relative location of the depot subdirectory relative to the Perforce server's P4ROOT. It must contain the ... wildcard; for example, a local depot foo might have a Map: of foo/... . If the Type: is remote, the map should be a location in the remote depot's physical namespace, for example, //depot/foo/bar/... . This directory will be the root of the local proxy depot.

Options

-d depotname	Delete the depot depotname. The depot must not contain any files; the Perforce superuser can remove files with p4 obliterate. If the depot is remote, p4 obliterate must still be run: no files are deleted, but any outstanding client or label records referring to that depot are eliminated.
-i	Read a depot specification from standard input.
-o	Write a depot specification to standard output.
g_opts	See the Global Options section.

Usage Notes

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
N/A	N/A	super

• A depot created with p4 depot is not physically created in the server until files have been added to it with p4 add.

• Users will not be able to access a new depot created with p4 depot until permission to access the depot is granted with p4 protect.

• Remote depots are always accessed by a virtual user named remote, and by default, all files on any Perforce server may be accessed remotely. To limit or eliminate remote access to a particular server, use p4 protect to set permissions for user remote on that server.

For example, to eliminate remote access to all files in all depots on a particular server, set the following permission on that server:

read user remote * -//...

Since remote depots can only be used for read access, it is not necessary to remove write or super access.

The virtual user remote does not consume a Perforce license.

Related Commands

To view a list of all depots known to the Perforce server	p4 depots
To populate a new depot with files	p4 add
To add mappings from an existing client workspace to the new depot	p4 client
To remove all traces of a file from a depot	p4 obliterate
To limit remote access to a depot	p4 protect