| |||||||||||||||||||||||||
|
Chapter 16 System Administration: Superuser Commands and Flags | |||||||||||||||||||||||||
|
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. Additionally, a special flag (-f) available with certain commands allows the superuser to perform operations unavailable to ordinary users.
| |||||||||||||||||||||||||
File Verification by Signature | |||||||||||||||||||||||||
|
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
| |||||||||||||||||||||||||
File Obliteration | |||||||||||||||||||||||||
|
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.
| |||||||||||||||||||||||||
Changelist Deletion & Description Editing | |||||||||||||||||||||||||
|
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.
| |||||||||||||||||||||||||
Distributed Depots | |||||||||||||||||||||||||
|
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. Defining New DepotsNew 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:
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. Defining Local DepotsTo 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:
Defining Remote DepotsDefining 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: |
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 Mapping Field,and What it MeansThe 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:
Naming DepotsDepot 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.Accessing Files In Other DepotsFiles 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:
| ||||||||||||||||||||||||