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

P4 CLI Documentation | 2026.1

# p4 depot

Create, edit, or delete a depot specification.

A branch, depot, label, and workspace cannot share the same name.

## Syntax

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

Syntax and naming conventions

## Description

The P4 Server stores files in shared repositories called depots. By default, there is one `local` depot named `depot` on every P4 Server installation.

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

Specifying the `-t` option creates a depot spec for the depot type you specify. For example:

    p4 depot -t stream mystreamdepot

Creates:

Copy

    Depot:        mystreamdepot
    Owner:        user
    Date:         2018/12/21 15:57:50
    Description:  Created by user.
    Type:         stream
    StreamDepth:  //mystreamdepot/1
    Map:          mystreamdepot/...

You can edit this spec. To change the StreamDepth, see Working with stream depots.

Alternatively, you can pipe the output stream to the `p4 depot` command:

    p4 depot -o [-t stream] mystreamdepot | p4 depot -i

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 the ability to access the depot is granted with `p4 protect`.

S3 storage is supported for all depot types except remote. To learn more, see S3 storage in the P4 Server Administration Documentation.

This command behaves differently for depots of type `graph`. For details, see the section Working with depots of type graph.

## Form fields

Field Name | Type | Description
--- | --- | ---
`Depot:` | Read-Only | The depot name as provided in `p4 depot depotname`. Be aware of the Limitations on characters in filenames and entities.
`Owner:` | Writable | The user that owns the depot. By default, the owner is the user who created the depot. The specified owner does not have to be a P4 Server user. You might want to use an arbitrary name if the owner does not yet exist, or if you have deleted the owner and need a placeholder until you can assign the spec to a new owner.
`Description:` | Writable | A short description of the depot’s purpose. Optional.
`Type:` | Writable | local, `remote`, `stream`, `spec`, `unload`, `archive`, `tangent`, `graph`, or `trait`. A `local` depot is writable, and is the default depot type. Files reside in the P4 Server root directory and are managed directly by the server. By default, there is one `local` depot named `depot` on every P4 Server installation. A `remote` depot references files that reside on other servers, and cannot be written to. See Working with remote depots. A `stream` depot is also writable, but contains streams, a type of branch that includes hierarchy and policy. See Working with stream depots. The `spec` depot, if present, automatically archives edited forms. See Working with spec depots. The `unload` depot, if present, holds infrequently-used metadata (about old client workspaces and labels) that has been unloaded with the `p4 unload` command. To learn more, see Unloading infrequently-used metadata in the P4 Server Administration Documentation. An `archive` depot is used in conjunction with the `p4 archive` and `p4 restore` commands to facilitate offline (or near-line) storage of infrequently-accessed file revisions, typically large binaries. A `tangent` depot defines a read-only location that holds tangents created by the `p4 fetch -t` command. The tangent depot named `tangent` is automatically created by `p4 fetch -t` if one does not already exist. A depot of type `graph` can contain Git repos. An extension depot stores files related to P4 Extensions. See P4 Server Administration Documentation. A `trait` depot defines a storage location to which newly-created huge attribute traits can be stored. This is an alternative to the default of storing attribute traits in the `db.traits` table. The storage location behavior is determined by the p4 attribute command or by setting the trait.storagedepot.min configurable higher than `0`. A server can contain only one `trait` depot.
`Address:` | Writable | If the `Type:` is `remote`, the address represents the `P4PORT` address of the remote server. If using S3 storage and the Type is not remote, the mapping for the S3 storage datasource. To learn more, see S3 storage in the P4 Server Administration Documentation.
`Suffix:` | Writable | 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 P4 Server ’s versioned specs enables users of GUI client software to associate these specifications with a preferred text editor. If the `Type:` is `local` or `remote`, this field is ignored.
`StreamDepth:` | Writable | The default is one level below the name of the depot. You can set a different value when you create the stream. See Working with stream depots.
`Map:` | Writable | 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. See Providing map information.
`SpecMap:` | Writable | For spec depots, an optional description of which specs should be saved, expressed as a view.

## Options

Option | Description
--- | ---
`-d depotname` | Delete the depot depotname.
A classic depot must not contain any files. The P4 Server user with the `super` access level can permanently remove files with `p4 obliterate`. | A stream depot must not contain any streams. A P4 Server user with the `admin` access level can can use the `--obliterate` option of p4 stream to permanently remove a stream.
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. The name of a depot cannot be the same as the name of a branch, client workspace, or label.
`-f` | 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. The P4 Server will not delete files on disk if they are referenced elsewhere (due to being branched or integrated to another depot as a lazy copy A method to conserve disk space by referencing files instead of duplicating their content.). You should not remove referenced files from disk manually using operating system commands. For more information, see Deleting depots.
`-i` | Read a depot specification from standard input, or from a file in the case of p4 depot -o -t stream mystreamdepot2 > filename where content of filename is the depot spec.
`-o depotname` | Write a depot specification to standard output.
`-t type` | The type of the depot: `local`, `remote`, `spec`, `stream`, `unload`, `archive`, or `tangent`. To support Git workflows, a special type is `graph`.
`g-opts` | See Global options.

## Usage notes

Can file arguments use revision specifier? | Can file arguments use revision range? | Minimal access level required
--- | --- | ---
N/A | N/A | `super`

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

  If you introduce the `server.depot.root` form of addressing in an existing installation and you want to set it to a value other than `P4ROOT`:

  1. Update the existing depot `Map` values to be absolute.

  2. Set the `server.depot.root` variable.

  3. (Optional) Update your existing depot maps.

### Working with remote depots

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

Although the remote depots feature is still supported, alternatives that are less likely to cause performance problems are Distributed development using Fetch and Push and Distribution Server.

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 P4 Server application to read files from a different Perforce service.

Remote depots are restricted to read-only access. P4 Server applications cannot `add`, `edit`, `delete`, or `integrate` files in the depots on the other servers.

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

To learn more, see Remote depots and multi-server development in the P4 Server Administration Documentation.

### Working with spec depots

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

`//`specdepotname`/`formtype`/`objectname`[`suffix`]`

For example, if the spec depot is 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 the current set of client, depot, branch, label, typemap, group, user, and job forms.

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:

    SpecMap:
        //spec/...
        -//spec/protect/...

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

See Spec Depot in the P4 Server Administration Documentation.

### Working with stream depots

A stream is a special type of branch that has hierarchy and policy. A `stream` depot is the container for a set of streams. To create a stream depot, provide the following information to the Depot spec :

- Depot (for the name of the stream depot)
- Owner
- Date (of creation)
- Type (must be stream)
- StreamDepth

#### About StreamDepth

By default, the files in a stream are stored one (1) level below the depot name. For example:

    //myStreamDepot/myStream1
    //myStreamDepot/myStream2
    //myStreamDepot/myStream3

To specify a non-default value for the StreamDepth: field, use an integer or forward slashes.

By integer: |
    Depot:	myStreamDepot
    Owner:	bruno
    Date:	2018/11/21 11:10:32
    Description:
    Created by bruno.
    Type:	stream
    Address: local
    Suffix:  .p4s
    StreamDepth: 2
By number of forward slashes, which in this case is 2: |
    Depot:	myStreamDepot
    Owner:	bruno
    Date:	2018/11/21 11:10:32
    Description:
    Created by bruno.
    Type:	stream
    Address: local
    Suffix:  .p4s
    StreamDepth: //myStreamDepot/foo/bar

You might want to create a stream that corresponds to a particular project, group, or location. For example, you can use
StreamDepth: //deepStream/1/2/3/4
or
StreamDepth: 4

However, for simplicity, we recommend a StreamDepth of 3 or less. If you want a StreamDepth of 3, such as:

    //myStream/organization/project/mainline
    //myStream/organization/project/dev
    //myStream/organization/project/release1
    //myStream/organization/project/release2

specify the value for the StreamDepth: field in one of the following two ways:

StreamDepth: 3

or

StreamDepth: //myStream/1/2/3

A stream's name and StreamDepth can only be assigned once. After that, you cannot rename a stream or change its depth.

For a complete explanation of the different types of streams and how to use them, see the chapter on Streams.

### Working with depots of type graph

A depot of type `graph` is used to store Git repos in the P4 Server.

To create a depot of type `graph` named `graphDepot1`, issue the following command:

    p4 depot -t graph graphDepot1

To display a list of depots of type `graph`, issue the following command:

    p4 depots -t graph

A default depot of type graph named `repo` is automatically created when the P4 Server server is created or upgraded to 2017.1 or later.

After you create a Git repo or a graph depot, `p4 depots` lists all depots, whether or not they are of type `graph`.

A depot of type `graph` does not use the `p4 protect` mechanism at the file level. Instead, a graph depot supports the Git model with a set of permissions for an entire repository (`repo`) of files. For details, see `p4 grant-permission`.

For in-depth information on working with depots of type `graph`, see Work with Git in P4 Server Administration Documentation.

## Related commands

To list all depots known to the P4 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`
To archive files into an archive depot | `p4 archive`
To restore files from an archive depot | `p4 restore`

Your search for returned results