p4 depot

Create, edit, or delete a depot specification.

Warning

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 conventions

Note

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

Description

The Helix Core Server stores files in shared repositories called depots. By default, there is one local depot named depot on every Helix Core 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:

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
Note

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.

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 Helix Core 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 Helix Core Server root directory and are managed directly by the server. By default, there is one local depot named depot on every Helix Core 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 Helix Core Server Administrator Guide.
  • 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 Helix Core Extensions. See Helix Core Extensions Developer Guide.

  • 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 should be the P4PORT address of the remote server.

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

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 Helix Core 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

-d depotname

Delete the depot depotname.

A classic depot must not contain any files. The Helix Core Server user with the super access level can permanently remove files with p4 obliterate. A stream depot must not contain any streams. A Helix Core 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.

-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

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 Helix Core Server application to read files from a different Perforce service. Remote depots are restricted to read-only access; Helix Core Server applications cannot add, edit, delete, or integrate files in the depots on the other servers. For more information about remote depots, see the Helix Core Server Administrator Guide.

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

See Remote depots and multi-server development in the Helix Core Server Administrator Guide.

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 Helix Core Server, and are represented in Helix Core 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 the Helix Core Server Administrator Guide on Spec Depot.

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
Tip

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

Important

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

Tip

For a complete explanation of the different types of streams and how to use them, see Streams in the Helix Core Command-Line (P4) Guide because the Helix Core Server Administrator Guide information on Stream Depots is minimal.

Working with depots of type graph

A depot of type graph is used to store Git repos in the Helix Core 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 Helix Core 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.

Note

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 Helix Core Server Administrator Guide.

Related commands

To list all depots known to the Helix Core 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