Open topic with navigation

p4 depot

Create or edit 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 Helix Core server stores files in shared repositories called depots. By default, there is one local depot named depot on every Helix Core 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, or graph.

Specifying the -t option creates a depot spec that is custom-made for the depot type you specify. For example, the following command:

$ p4 depot -o [-t stream] mystreamdepot

Creates the following depot spec:

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

You can edit this spec or you can pipe the output stream to the p4 depot command as follows to create the depot:

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

Form Fields

Options

Usage Notes

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 Helix Versioning Engine Administrator 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 Helix Versioning Engine Administrator 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.

Working with stream depots

You use a stream depot to store the streams you create and work with. You need to provide the following information when creating a stream depot: name, owner, date, type, and stream depth.

By default, the stream depth is 1, which specifies that streams are stored one level below the depot name. For example:

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

You can specify a different depth when you create the stream depot. This determines the subdirectory level where you want to root your streams. For example, if you specify 3 for StreamDepth, your depot might look like one of these:

//myStreamDepot/A/B/myStream1
//myStreamDepot/A/B/myStream2
//myStreamDepot/A/C/myStream3

You might want to increase the stream depth to identify the project to which your streams belong or to identify the organizational group that is responsible for those streams. In general, it is best to keep the depth as low as possible.

Observe the following limitations with respect to stream depth:

• All streams in a stream depot must be rooted at the same subdirectory level, which is given by the value of StreamDepth.

• You may not change the name of a stream.

  For example if a stream is named as follows:

  //myStreamDepot/A/B/myStream1

  You cannot rename it either to this (changing the depth of the stream):

  //myStreamDepot/A/myStream1

  or this:

  //myStreamDepot/A/B/myNewStream

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 is created or upgraded to 2017.1.

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

For in-depth information on working with depots of type graph, see Helix4Git Administrator Guide.

Related Commands