Create or edit a depot specification
The files on a Perforce server are stored in a depot. By default, there is one depot on every Perforce server, and its name is depot; however, it is possible to create multiple depots on a single server with the p4 depot command. Although it is normally not necessary to create multiple depots, there are two situations where this might be desirable:
In the latter case, the p4 client's local p4d server program acts as a proxy client to the remote server programs, so the client doesn't need to know where the files are actually stored. The use of remote depots is restricted to read-only access; thus, a p4 client program can't add, edit, delete, or integrate files that reside in depots on other servers.
Once a second depot has been created, it can be used exactly as the depot depot is used. For example, to sync a file README in the bar directory of the depot foo, use p4 sync //foo/bar/README. It can also be used on the left-hand side of any client or branch view, exactly as the depot depot is used.
To create or edit a depot, use p4 depot depotname. This brings up a form with the following fields:
| Field Name | Type | Description |
|---|---|---|
| Depot: | Read-only | The depot name as provided in p4 depot depotname. |
| Owner: | Writable | The user who owns the depot. By default, this is the user who created the depot. |
| Description: | Writable | A short description of the depot's purpose. Optional. |
| Type: | Writable | local or remote. Local depots are writable; remote depots are proxies for depots on other servers, and can't be written to. |
| Address: | Writable | If the Type: is local, the address should be the word subdir. If the Type: is remote, the address should be the P4PORT address of the remote server. |
| Map: | Writable |
If the Type: is local, the map should be the relative location of the depot subdirectory relative to the p4d server's P4ROOT. It must contain the ... wildcard; for example, a local depot foo might have a Map: of foo/... .
If the Type: is remote, the map should be a location in the remote depot's physical namespace, for example, //depot/foo/bar/... . This directory will be the root of the local proxy depot. |
| -d depotname | Delete the depot depotname. The depot must not contain any files; the Perforce superuser can remove files with p4 obliterate. If the depot is remote, p4 obliterate must still be run: no files will be deleted, but any outstanding client or label records referring to that depot will be eliminated. |
| -i | Read a depot specification from standard input. |
| -o | Write a depot specification to standard output. |
| g_opts | See global options section. |
|
Can File Arg Use Revision Specifier? |
Can File Arg Use Revision Range? |
Minimal Access Level Required |
|---|---|---|
| <NA> | <NA> | super |
Since remote depots can only be used for read access, it is not necessary to remove write or super access.
The virtual user remote does not consume a Perforce license.
| To view a list of all depots known to the Perforce 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 |