Perforce 2005.1 Command Reference | ||
<< Previous Chapter p4 delete |
Table of Contents Index Perforce on the Web |
Next Chapter >> p4 depots |
To create or edit a depot, use p4 depot depotname and edit the fields in the form. Depots may be of type local, remote, or spec.
Other local depots work the same way the default depot is used. For example, to sync a file README in the rel2 directory of the depot new, add //new/rel2/... to the left-hand side of your client workspace mapping, and run p4 sync //new/rel2/README.
If you are using remote depots, your Perforce server (that is, the machine specified in P4PORT) is configured to permit your Perforce client program to read files from a different Perforce server. Remote depots are restricted to read-only access; Perforce client programs cannot add, edit, delete, or integrate files in the depots on the other servers. For more information about remote depots, see the Perforce User's Guide and the Perforce System Administrator's Guide.
The spec depot, if present, tracks changes to user-edited forms such as client workspace specifications, jobs, branch specifications, and so on. There can be only one spec depot per server. Files in the spec depot are automatically generated by the server, 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
For more information about setting up a spec depot, see the System Administrator's Guide.
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, remote, or spec. Local depots are writable; remote depots are proxies for depots residing on other servers, and cannot be written to. The spec depot, if present, archives edited forms. |
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. The default suffix is .p4s. You do not need a suffix to use the spec depot, but supplying a file extension to your Perforce server's versioned specs enables users of GUI client software to associate Perforce specifications with a preferred text editor. If the Type: is local or remote, this field is ignored. |
Map: |
Writable |
If the Type: is local or spec, set the map to point to the relative location of the depot subdirectory relative to the Perforce server's P4ROOT. 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. |
-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 are deleted, but any outstanding client or label records referring to that depot are eliminated. |
-i |
Read a depot specification from standard input. |
-o depotname |
Write a depot specification to standard output. |
See the Global Options section. |
Perforce 2005.1 Command Reference | ||
<< Previous Chapter p4 delete |
Table of Contents Index Perforce on the Web |
Next Chapter >> p4 depots |