Chapter 3
Administering Perforce:
Superuser Tasks

Most of the tasks described in this chapter requires that you have Perforce superuser (access level super) or administrator (access level admin) privileges as defined in the Perforce protections table. For more about controlling Perforce superuser access, and protections in general, see "Administering Perforce: Protections" on page 75.

Release 2004.2 of Perforce introduced a new authentication mechanism and a server-configurable security setting to govern password strength requirements and authentication method policy. For details, see "Authentication methods: passwords and tickets" on page 39 and "Server security levels" on page 41.

Basic Perforce Administration

• User maintenance tasks, including resetting passwords, creating users, disabling the automatic creation of users, and cleaning up files left open by former users

• Administrative operations, including setting the server security level, obliterating files to reclaim disk space, editing submitted changelists, verifying server integrity, defining file types to control Perforce's file type detection mechanism, and the use of the -f flag to force operations

Authentication methods: passwords and tickets

How password-based authentication works

The concept of the server security level, introduced in Release 2004.2, enables administrators to enforce password strength and existence requirements. See "Server security levels" on page 41 for details.

Password based authentication is supported at security levels 0, 1, and 2.

How ticket-based authentication works

Tickets have a finite lifespan, after which they cease to be valid. By default, tickets are valid for 12 hours (43200 seconds). To set different ticket lifespans for groups of users, edit the Timeout: field in the p4 group form for each group. The timeout value for a user in multiple groups is the largest timeout value for all groups of which a user is a member. To create a ticket that does not expire, set the Timeout: field to 0.

Although tickets are not passwords, Perforce servers accept valid tickets wherever users can specify Perforce passwords. This behavior provides the security advantages of ticket-based authentication with the ease of scripting afforded by password authentication. Ticket-based authentication is supported at all server security levels, and is required at security level 3.

Logging in to Perforce

p4 login

By default, Perforce tickets are valid for your IP address only. If you have a shared home directory that is used on more than one machine, you can log in to Perforce from both machines by using the command:

p4 login -a

Logging out of Perforce

p4 logout

If you are logged in to Perforce from more than one machine, you can log out of Perforce from all machines from which you were logged in by using the command:

p4 logout -a

Determining ticket status

p4 login -s

To display all tickets you currently have, use the command:

p4 tickets

Server security levels

p4 counter -f security seclevel

Choosing a server security level

To ensure that all users have passwords, use security level 1. Users of old client programs can still enter weak passwords.

To ensure that all users have strong passwords, use security level 2. Old Perforce software continues to work, but users of old Perforce client software must change their password to a strong password by using a Perforce client program at Release 2003.2 or above.

To require that all users have strong passwords, and to require the use of session-based authentication, use security level 3 and current Perforce client software.

Level 0 corresponds to pre-2003.2 server operation. Levels 1 and 2 were designed for support of legacy client software. Level 3 affords the highest degree of security.

The Perforce server security levels and their effects on the behavior of Perforce client programs are defined below.

Password strength

• The password contains uppercase letters.

• The password contains lowercase letters.

• The password contains nonalphabetic characters.

Resetting user passwords

• Release 99.1 and later:
  p4 passwd username

When prompted, enter a new password for user username.

• Pre-99.1 releases:
  p4 user -f username

Enter the password in the Password: field of the user specification form.

Creating users

p4 user -f username

The p4 user command also has an option (-i) to take its input from the standard input instead of the forms editor. To quickly create a large number of users, write a script that reads user data, generates output in the format used by the p4 user form, and then pipes each generated form to p4 user -i -f.

Preventing creation of users

To prevent Perforce from automatically creating users, all users must be defined in the protections table. The easiest way to do this is to include all users in a Perforce group, and to configure Perforce to grant access only to members of that group.

Example:  Setting up users in a group

A Perforce superuser wants to prevent the server from creating new users. He starts by setting up a group called p4users for the three users currently at his site. He types:

p4 group p4users

and fills in the form as follows:

# A Perforce Group Specification. # Group:      The name of the group. # MaxResults: A limit on the results of operations for users in #             this group, or 'unlimited'. # MaxScanRows:A limit on data scanned during operations for users #             in this group, or 'unlimited'. # Timeout:    Time in seconds which determines how long a 'p4 login' #             session ticket remains valid (default is 12 hours). # Subgroups:  Other groups automatically included in this group. # Users:      The users in the group.  One per line. Group:  p4users MaxResults:     unlimited MaxScanRows:    unlimited Timeout:        43200 Subgroups: Users:         edk         lisag

He then uses p4 protect to edit the protections table. The relevant line of the default protections table looks like this:

write user * * //...

This grants write permission to any user matching * (that is, to all users) from any host (the second *) in all areas of the depot (that is, to files in //...).

Finally, the superuser uses p4 protect to change this line in the protections table to read:

write group p4users * //...

The replacement protection grants only write access to users whose group matches p4users. Members of p4users can use Perforce from any host (*) and have write access to all areas of the depot (//...).

As long as no other lines in the protections table grant permission to all users, all users are now defined within p4 protect, and the server no longer automatically creates new user entries when new users attempt to access Perforce.

For a more in-depth description of Perforce protections, see "Administering Perforce: Protections" on page 75.

Deleting obsolete users

p4 user -d -f username

Deleting a user frees a Perforce license but does not automatically update the group and protections tables. Use p4 group and p4 protect to delete the user from these tables.

Reverting files left open by obsolete users

As an example, if the output of p4 opened includes:

//depot/main/code/file.c#8 - edit default change (txt) by jim@stlouis

p4 client -d -f stlouis

Reclaiming disk space by obliterating files

Warning!

Use p4 obliterate with caution. This is the only command in Perforce that actually removes file data.

Perforce administrators can use p4 obliterate filename to remove all traces of a file from a depot, making the file indistinguishable from one that never existed in the first place.

By default, p4 obliterate filename does nothing; it merely reports on what it would do. To actually destroy the files, use p4 obliterate -y filename.

To destroy only one revision of a file, specify only the desired revision number on the command line. For instance, to destroy revision 5 of a file, use:

p4 obliterate -y file#5

p4 obliterate -y file#5,7

Warning!

If you intend to obliterate a revision range, be certain you've specified it properly. If you fail to specify a revision range, all revisions of the file are obliterated. The safest way to use p4 obliterate is to use it without the -y flag until you are certain the files and revisions are correctly specified.

Removing lazy copies by using the -z flag typically increases disk space usage. The only practical use of p4 obliterate -y -z is to undo lazy copies in order to enable you to manually remove archive files without breaking any linked metadata that points to the deleted files.

If a user sees the following error message while trying to access files:

Operation:user-sync
Librarian checkout path failed

Deleting changelists and editing changelist descriptions

You can also use the -f flag to delete any submitted changelists that have been emptied of files with p4 obliterate. The full syntax is p4 change -d -f changenumber.

Example:  Updating changelist 123 and deleting changelist 124

Use p4 change with the -f (force) flag:

p4 change -f 123
p4 change -d -f 124

The User: and Description: fields for change 123 are edited, and change 124 is deleted.

Verifying files by signature

It is good practice to run p4 verify before performing your nightly system backups, and to proceed with the backup only if p4 verify reports no corruption.

For large installations, p4 verify can take some time to run. Furthermore, the database is locked when p4 verify is running, which prevents most other Perforce commands from being used. Administrators of large sites might want to perform p4 verify on a weekly basis, rather than a nightly basis.

If you ever see a BAD! signature during a p4 verify command, your database or versioned files might be corrupt, and you should contact Perforce Technical Support.

Verifying files during server upgrades

1. Before the upgrade, run:
   p4 verify -q //...

   to verify the integrity of your server before the upgrade.

2. Take a checkpoint and copy the checkpoint and your versioned files to a safe place.

3. Perform the server upgrade.

4. After the upgrade, run:
   p4 verify -q //...

   to verify the integrity of your new system.

Defining filetypes with p4 typemap

Although this default behavior can be overridden by the use of the -t filetype flag, it's easy for users to overlook this consideration, particularly in cases where files' types are usually (but not always) detected correctly. Certain file formats, such as RTF (Rich Text Format) and Adobe PDF (Portable Document Format), can start with a series of comment fields or other textual data. If these comments are sufficiently long, such files can be erroneously detected by Perforce as being of type text.

The p4 typemap command solves this problem by enabling system administrators to set up a table that links Perforce file types with filename specifications. If an entry in the typemap table matches a file being added, it overrides the file type that would otherwise be assigned by the Perforce client program. For example, to treat all PDF and RTF files as binary, use p4 typemap to modify the typemap table as follows:

The first three periods ("...") in the specification are a Perforce wildcard specifying that all files beneath the root directory are to be included in the mapping. The fourth period and the file extension specify that the specification applies to files ending in .pdf (or .rtf).

The following table lists recommended Perforce file types and modifiers for common file extensions.

Use the following p4 typemap table to map all of the file extensions to the Perforce file types recommended in the preceding table.

For more information, see the p4 typemap page in the Perforce Command Reference.

Implementing sitewide pessimistic locking with p4 typemap

If you use this typemap, any files your users add to the depot after you update your typemap automatically have the +l modifier applied, and may only be opened for edit by one user at a time. The typemap table applies only to new additions to the depot; after you update the typemap table for sitewide exclusive open, files previously submitted without +l must be opened for edit with p4 edit -t+l filename and resubmitted. Similarly, users with files already open for edit must update their filetypes with p4 reopen -t+l filename.

Forcing operations with the -f flag

Advanced Perforce administration

Running Perforce through a firewall

The port on which the server listens is specified when the server is started. The number is arbitrary, so long as it does not conflict with any other networking services and is greater than 1024. The port number on the client machine is dynamically allocated.

A firewall is a network element that prevents any packets from outside a local (trusted) network from reaching that local network. This is done at a low level in the network protocol; any packets not coming from a trusted IP address are simply ignored.

In the following diagram, the Perforce client is on an untrusted part of the network. None of its connection requests reach the machine with the Perforce server. Consequently, the user running the client through the firewall is unable to use Perforce.

Secure shell

Secure shell (ssh) is meant to be a replacement for the UNIX rsh (remote shell) command, which allows you to log into a remote system and execute commands on it. The "secure" part of "secure shell" comes from the fact that the connection is encrypted, so none of the data is visible while it passes through the untrusted network. With simple utilities like rsh, all traffic, even passwords, is unencrypted and visible to all intermediate hosts, creating an unacceptable security hazard.

Secure shell is available for free in source form for a multitude of UNIX platforms from http://www.openssh.com. This page also links to ports of ssh for OS/2 and Amiga, as well as commercial implementations for Windows and Macintosh from Data Fellows (http://www.datafellows.com) and SSH (http://www.ssh.com).

The OpenSSH FAQ can also be found online at the main site (http://www.openssh.com/faq.html).

Solving the problem

A good solution takes advantage of ssh's ability to forward arbitrary TCP/IP connections. By using ssh, you can make your Perforce client appear as though it's connecting from the firewall machine over the local (trusted) network. In reality, your client remains on your local machine, but all packets from your local machine are first sent to the firewall through the secure channel set up by ssh.

Suppose the Perforce server is on p4dbox.bigcorp.com, and the firewall machine is called firewall.bigcorp.com. In our example, we'll arbitrarily choose local port 4242, and assume that the Perforce server is listening on port 3710.

Packets ultimately destined for your client's port 4242 are first sent to the firewall, and ssh forwards them securely to your client. Likewise, connections made to port 4242 of the firewall machine will end up being routed to port 3710 of the Perforce server.

On UNIX, the ssh command on your own machine to set up and forward the TCP/IP connection would be:

ssh -L 4242:p4dbox.bigcorp.com:3710 firewall.bigcorp.com

All that remains is to tell the Perforce client to use port 4242 by setting the environment variable P4PORT to 4242.

Normally, setting P4PORT=4242 would normally indicate that we are trying to connect to a Perforce server on the local machine listening at port 4242. In this case, ssh takes the role of the Perforce server. Anything a client sends to port 4242 of the local machine is forwarded by ssh to the firewall, which passes it to the real Perforce server at p4dbox.bigcorp.com. Since all of this is transparent to the Perforce client, it doesn't matter whether the client is talking to an instance of ssh that's forwarding traffic from port 4242 of the local machine, or if it's talking to a real Perforce server residing on the local machine.

The only glitch is that there's a login session you don't normally want on the firewall machine.

This can be solved by running the following command:

ssh -L 4242:p4dbox.bigcorp.com:3710 firewall.bigcorp.com -f sleep 9999999 -f

This tells ssh on firewall.bigcorp.com to fork a long-running sleep command in the background after the password prompt. Effectively, this sets up the ssh link and keeps it up; there is no login session to terminate.

Finally, ssh can be configured to "do the right thing" so that it is unnecessary to type such a long command with each session. The Windows version of ssh, for instance, has a GUI to configure this.

One final concern: with port 4242 on the local machine now forwarded to a supposedly secure server, your local machine is part of the trusted network; it is prudent to make sure the local machine really is secure. The Windows version of ssh has an option to only permit local connections to the forwarded port, which is a wise precaution; your machine will be able to use port 4242, but a third party's machine will be ignored.

Specifying IP addresses in P4PORT

Although this isn't the default behavior, it can be useful. For instance, if you want to configure p4d to listen only to a specific network interface or IP address, you can force your Perforce server to ignore all nonlocal connection requests by setting P4PORT=localhost:port.

Running from inetd on UNIX

p4dservice stream tcp nowait username /usr/local/bin/p4d p4d -i -rp4droot

p4dservice nnnn/tcp

• p4dservice is the service name you choose for this Perforce server

• /usr/local/bin is the directory holding your p4d binary

• p4droot is the root directory (P4DROOT) to use for this Perforce server (for example, /usr/local/p4d)

• username is the UNIX user name to use for running this Perforce server

• nnnn is the port number for this Perforce server to use

This method is an alternative to running p4d from a startup script. It can also be useful for providing special services; for example, at Perforce, we have a number of test servers running on UNIX, each defined as an inetd service with its own port number.

There are caveats with this method:

• inetd may disallow excessive connections, so a script that invokes several thousand p4 commands, each of which spawns an instance of p4d via inetd can cause inetd to temporarily disable the service. Depending on your system, you might need to configure inetd to ignore or raise this limit.

• There is no easy way to disable the server, since the p4d executable is run each time; disabling the server requires modifying /etc/inetd.conf and restarting inetd.

Case sensitivity and multiplatform development

For example, //depot/main/file.c and //depot/MAIN/FILE.C were treated as two completely different files. This caused problems where users on UNIX were connecting to a Perforce server running on Windows because the filesystem underlying the server could not store files with the case-variant names submitted by UNIX users.

In release 97.3, the behavior was changed, and only the UNIX server supports case-sensitive names. However, there are still some case-sensitivity problems that users can encounter when sharing development projects across UNIX and Windows.

If you are running a pre-97.2 server on Windows, please contact [email protected] to discuss upgrading your server and database.

For current releases of the server:

• The Perforce server on UNIX supports case-sensitive names.

• The Perforce server on Windows ignores case differences.

• Case is always ignored in keyword-based job searches, regardless of platform.

To find out what platform your Perforce server runs on, use p4 info.

Perforce server on UNIX

Conversely, Windows users will have to be careful to use case consistently in filenames and pathnames when adding new files. They might not realize that files added as //depot/main/one.c and //depot/MAIN/two.c will appear in two different directories when synced to a UNIX user's workspace.

The UNIX Perforce server always respects case in client names, label names, branch view names, and so on. Windows users connecting to a UNIX server should be aware that the lowercased workstation names are used as the default names for new client workspaces. For example, if a new user creates a client spec on a Windows machine named ROCKET, his client workspace is named rocket by default. If he later sets P4CLIENT to ROCKET (or Rocket), Perforce will tell him his client is undefined. He must set P4CLIENT to rocket (or unset it) to use the client workspace he defined.

Perforce server on Windows

For example, users who try something like this:

p4 add dir/file1
p4 add dir/file2
p4 add DIR/file3

Monitoring server activity

Enabling process monitoring

p4 counter -f monitor 1

Enabling idle processes monitoring

p4 counter -f monitor 2

Listing running processes

p4 monitor show

pid status owner hh:mm:ss command [args]

To show the arguments with which the command was called, use the -a (arguments) flag:

To obtain more information about user environment, use the -e flag. The -e flag produces output of the form:

pid client IP-address status owner workspace hh:mm:ss command [args]

By default, all user names and (if applicable) client workspace names are truncated at 10 characters, and lines are truncated at 80 characters. To disable truncation, use the -l (long-form) option:

Only Perforce administrators and superusers can use the -a, -l, and -e options.

Marking processes for termination

Once marked for termination, the process is terminated by the Perforce server within 50000 scan rows or lines of output. Only processes that have been running for at least ten seconds can be marked for termination.

Users of terminated processes are notified with the following message:

Command has been canceled, terminating request

Clearing entries in the process table

Perforce administrators and superusers can remove these erroneous entries from the process table altogether with p4 monitor clear pid, where pid is the erroneous process ID. To clear all processes from the table (running or not), use p4 monitor clear all.

Running processes removed from the process table with p4 monitor clear continue to run to completion.

Perforce server trace and tracking flags

p4d -r /usr/perforce -v server=1 -p 1666 -L /usr/perforce/logfile

Setting server debug levels on a Perforce server (p4d) has no effect on the debug level of a Perforce Proxy (p4p) process, and vice versa.

In most cases, the Perforce server command tracing and tracking flags are useful only to system administrators working with Perforce Technical Support to diagnose or investigate a problem.

Command tracing

For command tracing, output appears in the specified log file, showing the date, time, username, IP address, and command for each request processed by the server.

Performance tracking

Performance tracking is enabled by default, and if P4DEBUG is unset (or the tracking flag is not specified on the command line), the tracking level is computed based on the number of users in the license file.

The precise format of the tracking output is undocumented and subject to change.

Auditing user file access

Auditing is disabled by default, and is only enabled if P4AUDIT is set to point to the location of the audit log file, or if the server is started with the -A auditlog flag.

When auditing is enabled, the server adds a line to the audit log file every time file content is transferred from the server to the client. On an active server, the audit log file will grow very quickly.

Lines in the audit log appear in the form:

date time user@client clientIP command file#rev For example:

If a command is run on the machine that runs the Perforce Server, the clientIP is shown as 127.0.0.1.

Moving a Perforce server to a new machine

• of identical architectures,

• of different architectures using the same text file (CR/LF) format, or

• of different architecture and different text file format.

The Perforce server stores two types of data under the Perforce root directory: versioned files and a database containing metadata describing those files. Your versioned files are the ones created and maintained by your users, and your database is a set of Perforce-maintained binary files holding the history and present state of the versioned files. In order to move a Perforce server to a new machine, both the versioned files and the database must be successfully migrated from the old machine to the new machine.

For more about the distinction between versioned files and database, as well as for an overview of backup and restore procedures in general, see "Backup and recovery concepts" on page 25.

For more about moving a Perforce server from one machine to another, see also the Perforce Tech Note at:

http://www.perforce.com/perforce/technotes/note010.html

Moving between machines of the same architecture

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.

Moving between different architectures that use the same text format

Although the versioned files are portable across architectures, the database, as stored in the db.* files, is not. To transfer the database, you will need to create a checkpoint of your Perforce server on the old machine and use that checkpoint to re-create the database on the new machine. The checkpoint is a text file that can be read by a Perforce server on any architecture. For more details, see "Creating a checkpoint" on page 26.

After you create the checkpoint, you can use tar, cp, xcopy.exe, or any other method to copy the checkpoint file and the depot directories to the new machine. (You don't need to copy the db.* files, because they will be re-created from the checkpoint you took.)

1. On the old machine, use p4 verify to ensure that the database is in a consistent state.

2. On the old machine, stop p4d.

3. On the old machine, create a checkpoint:
   p4d -jc checkpointfile

4. 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.

   (To be precise, you don't need to copy the db.* files, just the checkpoint and the depot subdirectories. The db.* files will be re-created from the checkpoint. If it's more convenient to copy everything, then copy everything.)

5. On the new machine, if you copied the db.* files, be sure to remove them from the new P4ROOT before continuing.

6. Re-create a new set of db.* files suitable for your new machine's architecture from the checkpoint you created:
   p4d -jr checkpointfile

7. Start p4d on the new machine with the desired flags.

8. Run p4 verify on the new machine to ensure that the database and your versioned files were transferred correctly to the new machine.

Moving between Windows and UNIX

Depot subdirectories can contain both text and binary files. The text files (in RCS format, ending with ",v") and binary files (directories of individual binary files, each directory ending with ",d") need to be transferred in different ways in order to translate the line endings on the text files while leaving the binary files unchanged.

As with all other migrations, be sure to run p4 verify after your migration.

Contact Perforce Technical Support for assistance when migrating a Perforce server from Windows to UNIX.

Changing the IP address of your server

If you are a licensed Perforce customer, you will also need a new license file to reflect the server's new IP address. Contact Perforce Technical Support to obtain an updated license.

Changing the hostname of your server

Using multiple depots

Just as Perforce servers can host multiple depots, Perforce client programs can access files from multiple depots. These other depots can exist on the Perforce server normally accessed by the Perforce client, or they can reside within other, remote, Perforce servers.

Local depots reside on the Perforce server normally accessed by the user's Perforce client program. When using local depots, a Perforce client program communicates with the Perforce server specified by the user's P4PORT environment variable or equivalent setting.

When using remote depots, the user's Perforce client program uses the Perforce server specified by the user's P4PORT environment variable or equivalent setting as a means to access a second, remote, Perforce server. The local Perforce server communicates with the remote Perforce server in order to access a subset of its files. Remote depots are primarily used to facilitate the sharing of code (that is, "code drops") between separate organizations, and are discussed in "Remote depots and distributed development" on page 68.

Remote depots are not a generalized solution for load-balancing or network access problems. To support shared development or to deal with load-balancing or network access problems, see "Perforce Proxy" on page 139.

The spec depot is a special case. If present, the spec depot 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.

Naming depots

Defining new local depots

For example, to create a new depot called book with the files stored in the local Perforce server namespace in a root subdirectory called book (that is, $P4ROOT/book), enter the command p4 depot book, and fill in the resulting form as follows:

The Address: and Suffix: fields do not apply to local depots and are ignored.

By default, the Map: field on a local depot points to a depot directory matching the depot name, relative to the server root (P4ROOT) setting for your server. To store a depot's versioned files on another volume or drive, specify an absolute path in the Map: field. This path need not be under P4ROOT. Absolute paths in the Map: field on Windows must be specified with forward slashes (for instance, d:/newdepot/) in the p4 depot form.

Enabling versioned specifications with the spec depot

After you have enabled versioned specs by creating the spec depot, all user-generated forms (such as client workspace specifications, jobs, branch specifications, and so on) are automatically archived as text files in the spec depot. Filenames within the spec depot are automatically generated by the server, and are represented in Perforce syntax as follows:

//specdepotname/formtype/objectname[suffix]

The Address: field does not apply to spec depots and is ignored.

Using a Suffix: is optional, but specifying a file extension for objects in the spec depot simplifies usability for users of graphical client programs such as P4V or P4Win, because users can associate the suffix used for Perforce specifications with their preferred text editor. The default suffix for these files is .p4s.

For example, if you create a spec depot named spec, and use the default suffix of .p4s, your users can see the history of changes to job000123 by using the command

p4 filelog //spec/job/job000123.p4s

Listing depots

Deleting depots

To delete a depot, it must be empty; you must first obliterate all files in the depot with p4 obliterate.

For local and spec depots, p4 obliterate deletes the versioned files as well as all their associated metadata. For remote depots, p4 obliterate erases only the locally held client and label records; the files and metadata still residing on the remote server remain intact.

Before you use p4 obliterate, and especially if you're about to use it to obliterate all files in a depot, read and understand the warnings in "Reclaiming disk space by obliterating files" on page 45.

Remote depots and distributed development

• A "remote depot" is a depot on your Perforce server of type remote. It acts as a pointer to a depot of type "local" that resides on a second Perforce server.

• A user of a remote depot is typically a build engineer or handoff administrator responsible for integrating software between separate organizations.

• Control over what files are available to a user of a remote depot resides with the administrator of the remote server, not the users of the local server.

• See "Restricting access to remote depots" on page 71 for security requirements.

When to use remote depots

Partitioning joint development projects into separate Perforce installations does not improve throughput, and usually only complicates administration. If your site is engaged in distributed development (that is, developers in multiple sites working on the same body of code), it is usually preferable to set up a Perforce installation with all code in depots resident on one Perforce server, and to cache frequently accessed files at each development site with Perforce Proxy.

If, however, your organization regularly imports or exports material from other organizations, you might want to consider using Perforce's remote depot functionality to streamline your code drop procedures.

How remote depots work

In this example, an administrator of a Perforce server at oak:1234 is retrieving a file from a remote server at pine:1818.

Although it is possible to permit individual developers to sync files from remote depots into their client workspaces, this is generally an inefficient use of resources.

The preferred technique for using remote depots is for your organization's build or handoff administrator to integrate files from a remote depot into an area of your local depot. After the integration, your developers can access copies of the files from the local depot into which the files were integrated.

To accept a code drop from a remote depot, create a branch in a local depot from files in a remote depot, and then integrate changes from the remote depot into the local branch. This integration is a one-way operation; you cannot make changes in the local branch and integrate them back into the remote depot. The copies of the files integrated into your Perforce installation become the responsibility of your site's development team; the files on the depot remain under the control of the development team at the other Perforce installation.

Restrictions on remote depots

Remote depots facilitate the sharing of code between organizations (as opposed to the sharing of development within a single organization). Consequently, access to remote depots is restricted to read-only operations, and server metadata (information about client workspaces, changelists, labels, and so on) cannot be accessed using remote depots.

Using remote depots for code drops

• The Perforce administrator at the site receiving the code drop must create a remote depot on his or her Perforce server that points to the site providing the code drop.

This is described in "Defining remote depots" on page 70.

• The Perforce administrator at the site providing the code drop should configure his or her Perforce server to allow the recipient site's remote depot to access the providing site's Perforce server.

This is described in "Restricting access to remote depots" on page 71.

• The configuration manager or integration manager at the receiving site must integrate the desired files from the remote depot into a local depot under his or her control.

This is described in "Receiving a code drop" on page 72.

Defining remote depots

1. Create the depot with p4 depot depotname.

2. Set the Type: to remote.

3. Direct your Perforce server to contact the remote Perforce server by providing the remote server's name and listening port in the Address: field.

   A remote server's host and port are specified in the Address: field just as though it were a P4PORT setting.

4. Set the Map: field to map into the desired portion of the remote server's namespace.

   For remote depots, the mapping contains a subdirectory relative to the remote depot namespace. For example, //depot/outbound/... maps to the outbound subdirectory of the depot named depot hosted on the remote server.

   The Map: field must contain a single line pointing to this subdirectory, specified in depot syntax, and containing the "..." wildcard on its right side.

   If you are unfamiliar with client views and mappings, see the P4 User's Guide for general information about how Perforce mappings work.

5. The Suffix: field does not apply to remote depots; ignore this field.

Example:  Defining a remote depot

Lisa is coordinating a project and wants to provide a set of libraries to her developers from a third-party development shop. The third-party development shop uses a Perforce server on host pine that listens on port 1818. Their policy is to place releases of their libraries on their server's single depot depot under the subdirectory outbound.

Lisa creates a new depot from which she can access the code drop; she'll call this depot from- pine; she'd type p4 depot from-pine and fill in the form as follows:

Depot:       from-pine Type:        remote Address:     pine:1818 Map:         //depot/outbound/...

This creates a remote depot called from-pine on Lisa's Perforce server; this depot (//from- pine) maps to the third party's depot's namespace under its outbound subdirectory.

Restricting access to remote depots

By default, all the files on any Perforce server can be accessed remotely. To limit or eliminate remote access to a particular server, use p4 protect to set permissions for user remote on that server. Perforce recommends that administrators deny access to user remote across all files and all depots by adding the following permission line in the p4 protect table:

list user remote *  -//...

Example security configuration

On the local (oak) site:

• Deny access to //from-pine to all users. Developers at the oak site have no need to access files on the pine server by means of the remote depot mechanism.

• Grant read access to //from-pine to your integration or build managers. The only user at the oak site who requires access the //from-pine remote depot is the user (in this example, adm) who performs the integration from the remote depot to the local depot.

To accomplish this, the oak Perforce administrator should include the following lines to the p4 protect table:

list user * * -//from-pine/... read user adm * //from-pine/...

• Preemptively deny access to user remote across all depots from all IP addresses:

  list user remote * -//...

Adding these lines to the p4 protect table is sound practice for any Perforce installation whether its administrator intends to use remote depots or not.

• Grant read access to user remote to only those areas of the pine server into which code drops are to be placed. In this example, outgoing code drops are published in the //depot/outbound/... subdirectory on the pine server.

• Grant read access for user remote only to the IP address of the Perforce servers authorized to receive code drops. If oak's IP address is 192.168.41.2, the pine Perforce administrator should add the following to the p4 protect table:

  read user remote 192.168.41.2 //depot/outbound/...

Receiving a code drop

1. Developers on pine:1818 complete work on a body of code for delivery.

2. The build or release manager on pine:1818 branches the deliverable code into an area of pine:1818 intended for outbound code drops. In this example, the released code is branched to //depot/outbound/...

3. A Perforce administrator at oak:1234 configures a remote depot called //from-pine on the oak server. This remote depot contains a Map: field that directs the oak server to the //depot/outbound area of pine:1818.

4. Upon notification of the release's availability, a build or release manager at oak:1234 performs the code drop by integrating files in the //from-pine/... remote depot into a suitable area of the local depot, such as //depot/codedrops/pine.

5. Developers at oak:1234 can now use the pine organization's code, now hosted locally under //depot/codedrops/pine. Should patches be required to pine's code, oak developers can make such patches under //depot/codedrops/pine. The pine group retains control over its code.