p4 depot
Create, edit, or delete a depot specification.
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
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 mystreamdepotCreates:
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 | 
|---|---|---|
| 
 | Read-Only | The depot name as provided in  Be aware of the Limitations on characters in filenames and entities. | 
| 
 | 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. | 
| 
 | Writable | A short description of the depot’s purpose. Optional. | 
| 
 | Writable | local,  
 | 
| 
 | Writable | If the  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. | 
| 
 | Writable | If the  The default suffix is  If the  | 
| 
 | 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. | 
| 
 | Writable | If the  If the  | 
| 
 | Writable | For spec depots, an optional description of which specs should be saved, expressed as a view. | 
Options
| 
 | Delete the depot depotname. 
 If the depot is  The name of a depot cannot be the same as the name of a branch, client workspace, or label. | ||
| 
 | By default, when you delete a depot, the directory specified by
	      the  | ||
| 
 | 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. | ||
| 
 | Write a depot specification to standard output. | ||
| 
 | The type of the depot:  | ||
| 
 | 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 | 
 | 
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 ofP4ROOT, unless theserver.depot.rootconfigurable is set, in which case it is interpreted relative to the value of that variable.If you introduce the server.depot.rootform of addressing in an existing installation and you want to set it to a value other thanP4ROOT:- 
                                                            Update the existing depot Mapvalues to be absolute.
- 
                                                            Set the server.depot.rootvariable.
- 
                                                            (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..
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
For a complete explanation of the different types of streams and how to use them, see Streams in the P4 CLI Documentation because the P4 Server Administration Documentation 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 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 | |
| To populate a new depot with files | |
| To add mappings from an existing client workspace to the new depot | |
| To remove all traces of a file from a depot | |
| To limit remote access to a depot | |
| To archive files into an archive depot | |
| To restore files from an archive depot |