Perforce 使用笔记

Perforce requires at least two executables: the server (p4d), and at least one Perforce client
program (such as p4 on UNIX, or p4.exe on Windows).

If you have Administrator privileges, it is usually best to install Perforce as a service. If
you don’t, install it as a server.

Windows Installation

Use the Perforce installer program to install or upgrade the Perforce Server, Perforce
Proxy, or the Perforce Command-Line Client.

Windows services VS windows servers

To run any task as a Windows server, a user account must be logged in, because shortcuts
in a user’s Startup folder cannot be run until that user logs in. A Windows service, on the
other hand, is invoked automatically at boot time and runs regardless of whether or not a
user is logged in to the machine.

The Perforce service (p4s.exe) and the Perforce server (p4d.exe) executables are copies
of each other; they are identical apart from their filenames. When run, they use the first
three characters of the name with which they were invoked (that is, either p4s or p4d) to
determine their behavior. For example, invoking copies named p4smyserver.exe or
p4dmyservice.exe invokes a service and a server, respectively.

Starting and stopping the Perforce service

services.msc or user command line: p4 admin stop

Starting and stopping the Perforce server

The server executable, p4d.exe, is normally found in your P4ROOT directory. To start the
server, first make sure your current P4ROOT, P4PORT, P4LOG, and P4JOURNAL settings are
correct; then run: %P4ROOT%\p4d
To start a server with settings different from those set by P4ROOT, P4PORT, P4LOG, or
P4JOURNAL, use p4d command-line flags. For example:
c:\test\p4d -r c:\test -p 1999 -L c:\test\log -J c:\test\journal
starts a Perforce server process with a root directory of c:\test, listening to port 1999,
logging errors to c:\test\log, and with a journal file of c:\test\journal. The p4d
command-line flags are case-sensitive.
To stop the Perforce server, use the command:
p4 admin stop

Windows configuration parameter precedence

Under Windows, Perforce configuration parameters can be set in many different ways.
When a Perforce client program (such as p4 or P4V), or a Perforce server program (p4d)
starts up, it reads its configuration parameters according to the following precedence:
1. The program’s command-line flags have the highest precedence.
2. The P4CONFIG file, if P4CONFIG is set
3. User environment variables
4. System environment variables
5. The Perforce user registry (set by p4 set)
6. The Perforce system registry (set by p4 set -s)
When a Perforce service (p4s) starts up, it reads its configuration parameters from the
environment according to the following precedence:
1. Windows service parameters (set by p4 set -S servicename) have the highest
precedence.
2. System environment variables
3. The Perforce system registry (set by p4 set -s)
User environment variables can be set with any of the following:
• The MS-DOS set command
• The AUTOEXEC.BAT file
• The User Variables tab under the System Properties dialog box in the Control Panel
System environment variables can be set with:
• The System Variables tab under the System Properties dialog box in the Control Panel

Moving between machines of the same architecture

If the architecture of the two machines is the same (for example, SPARC/SPARC, or
x86/x86), the versioned files and database can be copied directly between the machines,
and you only need to move the server root directory tree to the new machine. You can use
tar, cp, xcopy.exe, or any other method. Copy everything in and under the P4ROOT
directory - the db.* files (your database) as well as the depot subdirectories (your
versioned files).
1. Back up your server (including a p4 verify before the backup) and take a
checkpoint.
2. On the old machine, stop p4d.
3. Copy the contents of your old server root (P4ROOT) and all its subdirectories on the
old machine into the new server root directory on the new machine.
4. Start p4d on the new machine with the desired flags.
5. Run p4 verify on the new machine to ensure that the database and your versioned
files were transferred correctly to the new machine.
(Although the backup, checkpoint, and subsequent p4 verify are not strictly necessary,
it’s always good practice to verify, checkpoint, and back up your system before any
migration and to perform a subsequent verification after the migration.)

Delete a workspace

From the "View" menu, select "Workspaces". You'll see all of the workspaces you've created. Select the workspaces you want to delete and click "Edit" -> "Delete Workspace", or right-click and select "Delete Workspace". If the workspace is "locked" to prevent changes, you'll get an error message.

To unlock the workspace, click "Edit" (or right-click and click "Edit Workspace") to pull up the workspace editor, uncheck the "locked" checkbox, and save your changes. You can delete the workspace once it's unlocked.

In my experience, the workspace will continue to be shown in the drop-down list until you click on it, at which point p4v will figure out you've deleted it and remove it from the list.