Installation of p4d and p4
PERFORCE operation requires two executables: p4d
, the server, and p4
, the client. If you haven't already downloaded these, they may be retrieved from http://www.perforce.com/perforce/load.html
.p4
program typically resides in /usr/local/bin
, and p4d
is usually located in /usr/local/bin
or in its own root directory (see below), although they can be installed anywhere. The p4
program can be installed on any server that has TCP/IP access to the p4d
host. To limit access to the p4d
server files, it is recommended that p4d
be owned and run by a Perforce user account.p4
and p4d
can be run: a root directory for the p4d
files is created, a TCP/IP port is provided to p4d
, and p4
is provided the name of the p4d
host and number of the p4d
port. These steps are described in the following sections. Creating a p4d Root Directory
p4d
stores all of its data in files and subdirectories of its own root directory, which can reside anywhere on the server system. This directory can be named anything at all, and the only necessary permissions are read and write for the user who starts p4d
. Since p4d
will store all submitted files in this directory, the size of the directory can eventually become quite large. Disk space management is described in section 10.8 .P4ROOT
should be set to point to this directory. Alternatively, the -r
flag can be provided when p4d
is started (see below). The p4
clients never directly use this directory, so they don't need to know the value of P4ROOT
. Setting p4d's Port
p4d
and p4
communicate via TCP/IP. When p4d
starts, it will, by default, listen on port 1666. The p4
client will, by default, assume that its p4d
server is located on host perforce, listening on port 1666.p4d
is to listen on a different port, the port can be specified with the -p
flag when starting p4d
(example: p4d -p 1818
), or the port can be set with the P4PORT
environment variable. Chances are that your p4d
host is not named perforce, but you can simplify life somewhat for your p4
users by setting perforce as an alias to the true host name in the host's /etc/hosts
file, or by doing so via Sun's NIS or Internet DNS. Telling p4 Where The p4d Server Is
The p4
client program needs to know on which TCP/IP port the p4d
server program is listening. p4
can be told which host and port the p4d
server program is listening on by setting each p4
user's P4PORT
environment variable to host:port# , where host is the name of the host that p4d
is running on, and port# is the port that p4d
is listening on.
If P4PORT is... |
Then... |
|
p4 will communicate with the p4d server on host dogs listening at port 3435.
|
|
p4 will communicate with the p4d server on host x.com listening on port 1818.
|
p4d
's P4PORT
and P4ROOT
environment variables have been set, p4d
can be run in the background with the commandp4d &
P4PORT
can be overridden by starting p4d
with the -p
flag, and P4ROOT
will be ignored if the -r
flag is provided. The startup command would then have this form:p4d -r /usr/local/p4files -p 1818 &
Although this command is sufficient to run
p4d
, other flags, which control such things as error logging, checkpointing, and journaling, can and should be provided. These flags are discussed in the next two sections.
p4d
program tries to ensure that all error messages reach the user, but if an error occurs and the client program disconnects before the error is sent, p4d
logs the error to its error output. The error output file can be specified with the -L
flag to p4d
, or can be defined in the environment variable P4LOG
. If no error output file is defined, errors are dumped to the p4d
program's standard error.
p4d
root directory are sufficient to recover the complete p4d server data:
p4d
stores its metadata in the top level of its root directory; all of these files are binary, and begin with "db.
".
p4
clients are stored in p4d
subdirectories that have the same names as the depots. By default, there is only one of these subdirectories; its name is depot
.
p4d
provides checkpointing and journaling facilities for recovery of the metadata database files. A checkpoint is just a snapshot or copy of the database files at a particular moment in time, and a journal is a log that records updates since that snapshot. If the database files become corrupted, or if there's a disk crash, you can recover the files by reloading the checkpoint and applying the changes stored in the journal. Both the checkpoint and journal are text files, and have the same format.Checkpointing and journaling archive only the database files, and NOT the files in the depot subdirectories!. After checkpointing, the depot files should be backed up with the standard OS backup commands. Checkpointing should be performed first, and only then should the standard OS backup be performed on the data files. This is because the static checkpoint can be dumped and restored consistently, while the dynamic database files may change during the course of backing up and may be inconsistent.
p4d
program with the -jc
flag:% p4d -r root -jc
This can be run while the
p4d
server is running. To make the checkpoint, p4d
locks the entire database and then dumps the database contents to a file named checkpoint.
x ,where x is a sequence number. Before unlocking the database, p4d
truncates the journal file if it exists. This action guarantees that the last checkpoint combined with the current journal always reflects the database.A different checkpoint file can be specified by typing a filename after the
-jc
flag:% p4d -r root -jc /disk2/perfback/ckp
A checkpoint file may be compressed, archived, or moved onto another disk. At that time or shortly thereafter, the files in the depot subdirectories should be archived as well. When recovering, the checkpoint must be no newer than the files in the depots.
The checkpoint file is often much smaller than the original database, and can be made smaller still by compressing it. The journal file, on the other hand, can grow quite large, but it is truncated whenever a checkpoint is made.
Regular checkpointing is important if journaling is turned on, to keep the journal from getting too long. Making a checkpoint just before dumping the file system is simply good practice.
-jc
flag, which is used to create a Perforce checkpoint, will also start a journal when certain other simple conditions are met. By default, the journal is written to the file journal in the p4d
root directory. The name and location of this file can be changed by specifying the name of the journal file in the environment variable P4JOURNAL
, or by providing a -J
filename flag to p4d
. In either case, the journal file name can be provided as an absolute path, or as a path relative to the p4d
server root.To create a journal, do one of the following:
p4d
with the -jc
flag;
P4JOURNAL
environment variable to point to any file, then call p4d
; or
p4d
with both the -jc
and -J
filename flags.
P4JOURNAL
, and type the p4d
command again without the -J
flag.Since there is no sure protection against disk crashes, the journal file and the
p4d
root directory should be located on different disks.
p4d
program itself, or a disk crash, the files can be recreated with your stored checkpoint and journal. To do this, kill p4d
, remove the database ("db.
") files, and then invoke the p4d
program with the -jr
flag:% rm root/db.*
After recovering the database you will need to restore the depot files with the UNIX restore command to ensure that they are as new as the database.
p4d
's stored source files reside in subdirectories of the p4d
root, as do its database files, and by default the checkpoint and journal. The stored source file depots are grow-only, and this can clearly present disk space problems on high use systems. The following approaches may be used to remedy this:
P4JOURNAL
environment variable or the -J
flag to p4d
.
-jc
chkptfile option with the p4d
command to write the checkpoint to a different disk. Or use the default checkpoint files, but backup your checkpoints and then delete them from the root directory. They aren't needed unless you are recovering.
p4d
server is not running.
p4d
root directory. It is a plain text file supplied by Perforce Software. Without this license file, the p4d
server will limit itself to two users and two client workspaces.The current licensing information can be viewed by invoking
p4d -V
from the server root directory.When the server is running, the license information can also be viewed with
p4 info
.
p4
client and p4d
server programs will display their version and license information with the -V
flag. The p4
info command will attempt to connect to the server and display its license information (among other things). Version information can also be gleaned from p4
or p4d
executables with the UNIX what(1)
command.