p4 depot


Create or edit a depot specification.


p4 [g-opts] depot depotname
p4 [g-opts] depot -d [-f] depotname
p4 [g-opts] depot -o depotname
p4 [g-opts] depot -i


The Perforce versioning service stores files in shared repositories called depots. By default, there is one depot on every Perforce installation, and its name is depot.

To create or edit a depot, use p4 depot depotname and edit the fields in the form. Depots can be of type local, stream, remote, archive, spec, or unload.

A depot created with p4 depot is not physically created on disk until files have been added to it with p4 add. Users are not able to access a new depot created with p4 depot until permission to access the depot is granted with p4 protect.

Form Fields

Field Name





The depot name as provided in p4 depot depotname.



The user who owns the depot. By default, this is the user who created the depot.

The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user.



A short description of the depot's purpose. Optional.



local, remote, spec, stream, unload, or archive.

Local depots are writable, and are the default depot type. Files reside in the server's root directory.

Stream depots are also writable, but contain streams, a type of branch that includes hierarchy and policy.

Remote depots reside on other servers, and cannot be written to. See Working with Remote Depots for more information.

The spec depot, if present, archives edited forms. See Working with Spec Depots for more information.

The unload depot, if present, holds infrequently-used metadata (about old client workspaces and labels) that has been unloaded with the p4 unload command. For more information, see the Perforce Server Administrator's Guide: Fundamentals.

Archive depots are used in conjunction with the p4 archive and p4 restore commands to facilitate offline (or near-line) storage of infrequently-accessed revisions, typically large binaries.



If the Type: is remote, the address should be the P4PORT address of the remote server.

If the Type: is local or spec, this field is ignored.



If the Type: is spec, this field holds an optional suffix for generated paths to objects in the spec depot. See Working with Spec Depots for more information.

The default suffix is .p4s. You do not need a suffix to use the spec depot, but supplying a file extension to your Perforce server's versioned specs enables users of GUI client software to associate Perforce specifications with a preferred text editor.

If the Type: is local or remote, this field is ignored.



If the Type: is local, spec, or archive, set the map to point to the relative location of the depot subdirectory. The map must contain the ... wildcard; for example, a local depot new might have a Map: of new/....

If the Type: is remote, set the map to point to a location in the remote depot's physical namespace, for example, //depot/new/rel2/.... This directory will be the root of the local representation of the remote depot.

For more information, see Providing Map Information.



For spec depots, an optional description of which specs should be saved, expressed as a view.


-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.


By default, when you delete a depot, the directory specified by the Map: field (typically under P4ROOT) must be empty. Use the -f option to remove all files even if the directory is not empty.


Read a depot specification from standard input.

-o depotname

Write a depot specification to standard output.


See “Global Options”.

Usage Notes

Can File Arguments Use Revision Specifier?

Can File Arguments Use Revision Range?

Minimal Access Level Required




Providing Map Information

For a local depot, the Map field specifies the filesystem location of the archive contents for files in the depot. This location can be either relative or absolute. To store a depot's versioned files on another volume or drive, specify an absolute path in the Map field. This path need not be under P4ROOT.

  • If the location is absolute, for example, /p4/depots/depot/..., no further interpretation is needed.

  • If the location is relative, for example, Ace/..., the location is interpreted relative to the value of P4ROOT, unless the server.depot.root configurable is set, in which case it is interpreted relative to the value of that variable.

    Take care if you introduce the server.depot.root form of addressing in an existing installation. If you want to set it to a value other than P4ROOT, you should first update your existing depot Map values to make sure they are all absolute. You can then set the server.depot.root variable without disrupting anything. After that, you can go back and update your existing depot maps if you so desire.

Working with Remote Depots

If you are using remote depots, the machine that hosts the Perforce service (that is, the machine specified in P4PORT) is configured to permit your Perforce application to read files from a different Perforce service. Remote depots are restricted to read-only access; Perforce applications cannot add, edit, delete, or integrate files in the depots on the other servers. For more information about remote depots, see the Perforce Server Administrator's Guide: Fundamentals.

Remote depots are accessed by a virtual user named remote (or, if configured, by the service user configured for the service that originates the request), and by default, all files on any Perforce installation can be accessed remotely. To limit or eliminate remote access to a particular server, use p4 protect to set permissions for user remote (or the accessing site's service user) 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 * -//...

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

Neither service users nor the virtual remote user consume Perforce licenses.

If your server accesses remote depots by means of a service user, your service user must have a valid ticket for the server that is hosting the remote depot.

Working with Spec Depots

The spec depot, if present, tracks changes to user-edited forms such as client workspace specifications, jobs, branch mappings, and so on. There can be only one spec depot per server. Files in the spec depot are automatically generated by Perforce, and are represented in Perforce syntax as follows:


For instance, if the spec depot is present and named spec, and uses the default suffix of .p4s, you can obtain the history of changes to job000123 by typing:

p4 filelog //spec/job/job000123.p4s

After you have created the spec depot, use p4 admin updatespecdepot to pre-populate it with current set of client, depot, branch, label, typemap, group, user, and job forms. For more information about setting up a spec depot, see the Perforce Server Administrator's Guide: Fundamentals.

For spec depots, the SpecMap: field can be used to control which specs are versioned. By default, all specs (//spec/...) are versioned. To exclude the protections table from versioning, configure the spec depot's SpecMap: as follows:


Adding or changing the spec mapping only affects future updates to the spec depot; files already stored in the spec depot are unaffected.

Related Commands

To list all depots known to the Perforce versioning service

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

To archive files into an archive depot

p4 archive

To restore files from an archive depot

p4 restore