p4 depot
Synopsis
Create or edit a depot specification.
Syntax
p4 [g-opts
] depot depotname
p4 [g-opts
] depot -d [-f] depotname
p4 [g-opts
] depot -o depotname
p4 [g-opts
] depot -i
Description
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 |
Type |
Description |
---|---|---|
|
Read-Only |
The depot name as provided in p4 depot
|
|
Writable |
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. |
|
Writable |
A short description of the depot's purpose. Optional. |
|
Writable |
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. |
|
Writable |
If the
If the |
|
Writable |
If the
The default suffix is
If the |
|
Writable |
If the
If the For more information, see Providing Map Information. |
|
Writable |
For spec depots, an optional description of which specs should be saved, expressed as a view. |
Options
|
Delete the depot
If the depot is |
|
By default, when you delete a depot, the directory specified by
the |
|
Read a depot specification from standard input. |
|
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 |
---|---|---|
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.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 thanP4ROOT
, you should first update your existing depotMap
values to make sure they are all absolute. You can then set theserver.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:
//
specdepotname
/formtype
/objectname
[suffix
]
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:
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.