Three Perforce commands can be used only by users with Perforce superuser privileges. These commands allow the superuser to verify files using 128-bit signatures, remove all traces of file from the depot, create multiple depots on the local server, or provide read access to files on other servers.
The p4 verify filenames command can be used to generate 128-bit signatures of each revision of the named files. A list of signatures generated by p4 verify can later be used to confirm proper recovery in case of a crash: if the signatures of the recovered files match the previously saved signatures, the files were recovered accurately.
For more information about the MD5 algorithm, which is used to generate the file signatures, please see <http://backupvault.com/md5.htm>.
The depot is always growing. Obviously, this is not always desirable: a branch might be performed incorrectly, creating hundreds of unneeded files; or perhaps there are simply a lot of old files around that are no longer being used. p4 delete won't help, since this command marks the file as deleted in its head revision, but leaves the old revisions intact.
p4 obliterate filename can be used by superusers to remove all traces of a file from a depot, making the file indistinguishable from one that never existed in the first place. p4 obliterate is so destructive, in fact, that we haven't even told you how it really works yet. p4 obliterate filename only reports on what it will do; to actually destroy the files, use p4 obliterate -y filename.
The -f flag can be used with p4 change to change the description or username of submitted changelists. The syntax is p4 change -f changenumber; this presents the standard changelist form, in which the description and/or username may be edited.
The -f flag can also be used to delete any submitted changelists that have been emptied of files with p4 obliterate. The full syntax is p4 change -d -f changenumber.
Perforce distributed depots allow the p4 client program to access files from multiple depots. These other depots may reside within the p4d server normally accessed by the p4 client program, or they may reside within other, remote, p4d servers.
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, and doesn't need direct access to the remote p4d server programs.
The use of distributed depots on remote servers is currently limited to read-only operations; thus, a p4 client program may not add, edit, delete or integrate files that reside in depots on other servers. Depots sharing the same p4d server as the client are not subject to this limitation.
New depots in a server namespace are defined with the command p4 depot depotname. If called with the default depotname depot, the p4 depot command will bring up the following form:
Depot Name: depot Type: local Address: subdir Map: depot/... |
When p4 depot depot is called, the form is filled in with values representing the state of the default depot. Its name, of course, is depot. It resides in the local p4d server namespace; so its type is local, (as opposed to remote). The Map: field indicates where the depot subdirectory is located relative to the root directory of the p4d server program; in this default case, the depot called depot starts in the depot subdirectory directly underneath the root.
To define a new local depot (that is, a new depot in the current p4d server program namespace), p4 depot is called with the new depot name, and only the Map: field in the resulting form need be changed. For example, to create a new depot called book with the files stored in the local p4d server namespace in a root subdirectory called manual, the command p4 depot book would be typed, and the resulting form would be filled in as follows:
Depot Name: book Type: local Address: subdir Map: manual/... |
Defining a new depot on a remote p4d server is only slightly more complicated. The Type: is remote; the server address must be provided in the Address: field, and the Map: field must be given a mapping into the remote depot namespace.
Lisa is working on a GUI for Elm. She and Ed are using different p4d servers; his is on host pine, and it's listening on port 1818. Lisa wants to grab Ed's GUI routines for her own use; she knows that Ed's color routine files are located on his p4d server's single depot under the subdirectory graphics/GUI. Lisa's first step towards accessing Ed's files would be to create a new depot. She'll call this depot gui; she'd type p4 depot GUI and fill in the form as follows:
Depot Name: gui
Type: remote
Address: pine:1818
Map: //depot/graphics/gui/...
This creates a remote depot called gui on Lisa's p4d server; this depot maps to Ed's depot's namespace under its graphics/gui subdirectory.
The Map: field is analogous to a client's view, except that the view may contain multiple mappings and the Map: field always contains a single mapping. This single mapping format changes depending on whether or not the depot being defined is local or remote:
Depot names share the same namespace as branches, clients, and labels. For example,
//foo refers unambiguously to either the depot foo, the client foo, the branch foo, or the label foo.
Files from any remote or local depot known to the default p4d server can be accessed simply by using the depot's name wherever the default depot name depot is usually used. This means that any defined depot name can be used in the following ways:
Client: spice Description: Created by Jake. Root: /usr/jake/src View: //depot/... //spice/local/... //foo/... //spice/remote/... |
Additionally, files from remote depots can't be used in p4 filelog or p4 describe, even though these operations are read-only.
A branch view may contain remote files in its mappings, so that files can be branched and later integrated from a remote depot into the local one. This works much as local branching and integration do, with two exceptions:
Depots may be deleted with p4 -d depotname.
All depots known to the current p4d server can be listed with the p4 depots command.