Perforce supports two methods of authentication: password-based and ticket-based.

Perforce superusers can configure server-wide password usage requirements, password strength enforcement, and supported methods of user/server authentication by setting the security configurable. To change the security configurable, issue the command:

p4 configure set security=seclevel

where seclevel is 0, 1, 2, 3, or 4.

The Perforce versioning service offers a mechanism to control which revisions of client applications are able to connect to Perforce.

To require a minimum revision, set the configurables minClient to the appropriate revision, and (optionally) set minClientMessage to the error message displayed when users of older applications connect to the server.

For example:

p4 configure set minClient=2010.2
p4 configure set minClientMessage="Please upgrade to 2010.2 or higher"

Certain combinations of server security level and Perforce applications require users to set "strong" passwords. A password is considered strong if it is at least dm.password.minlength characters long (by default, eight characters), and at least two of the following are true:

For example, the passwords a1b2c3d4, A1B2C3D4, aBcDeFgH are considered strong in an environment in which dm.password.minlength is 8, and the security is configurable to at least 1.

You can configure a minimum password length requirement on a sitewide basis by setting the dm.password.minlength configurable. For example, to require passwords to be at least 16 characters in length, a superuser can run:

p4 configure set dm.password.minlength=16

Passwords may be up to 1024 characters in length. The default minimum password length is eight characters.

Perforce superusers can manually set a Perforce user's password with:

p4 passwd username

When prompted, enter a new password the user.

To force a user with an existing password to reset his or her own password the next time they use Perforce, use the following command:

p4 admin resetpassword -u username

You can force all users with passwords (including the superuser that invokes this command) to reset their passwords by using the command:

p4 admin resetpassword -a

Running p4 admin resetpassword -a resets only the passwords of users who already exist (and who have passwords). If you create new user accounts with default passwords, you can further configure your installation to require that all newly-created reset their passwords before issuing their first command. To do this, set the dm.user.resetpassword configurable as follows:

p4 configure set dm.user.resetpassword=1

By default, Perforce creates a new user record in its database whenever a command is issued by a user that does not exist. Perforce superusers can also use the -f (force) flag to create a new user as follows:

p4 user -f username

Fill in the form fields with the information for the user you want to create.

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.

By default, Perforce creates a new user record in its database whenever a user invokes any command that can update the depot or its metadata. You can control this behavior by setting the dm.user.noautocreate configurable with the p4 configure command:

For example:

p4 configure set dm.user.noautocreate=1

changes the server's behavior to require that new users first create their own accounts before attempting to modify data on the server.

You can use the p4 renameuser command to rename users. The command renames the user and modifies associated artifacts to reflect the change: the user record, groups that include the user, properties that apply to the user, and so on. For detailed information see the description of the p4 renameuser command in the Perforce Command Reference. In general, the user name is not changed in descriptive text fields such as change descriptions. It is only changed where the name appears as the owner or user field of the database record.

For best results, follow these guidelines:

Each standard user on the system consumes one Perforce license. A Perforce administrator can free up licenses by deleting users with the following command:

p4 user -d -f username

Before you delete a user, you must first revert (or submit) any files a user has open in a changelist. If you attempt to delete a user with open files, Perforce displays an error message to that effect.

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.

Perforce licenses are controlled by a text file called license. This file resides in the server root directory.

To add or update a license file, stop the Perforce Server, copy the license file into the server root directory, and restart the Perforce Server.

You can update an existing license without shutting down the Perforce Server, use p4 license -i to read the new license file from the standard input.

Most new license files obtained from Perforce can be installed with p4 license , except for when the server IP address has changed. If the server IP address has changed, or if no license file currently exists, restart the Server with p4 admin restart.

Organizations whose system administrators do not use Perforce's versioning capabilities may be able to economize on licensing costs by using the operator user type.

The operator user type is intended for system administrators who, even though they have super or admin privileges, are responsible for the maintenance of the Perforce Server, rather than the development of software or other assets on the server.

There are three types of Perforce users: standard users, operator users, and service users. Standard users are the default, and each standard user consumes one Perforce license. Service users do not require licenses, but are restricted to automated inter-server communication processes in replicated and multiserver environments (see “Service users”). An operator user does not require a Perforce license, and can run only the following commands:

There are three types of Perforce users: standard users, operator users, and service users. A standard user is a traditional user of Perforce, an operator user is intended for human or automated system administrators, and a service user is used for server-to-server authentication, whether in the context of remote depots (see “Remote depots and distributed development”) or in distributed environments (see Distributing Perforce.)

Creating a service user for each Perforce service you install. Doing so can simplify the task of interpreting your server logs, but can also improve security by requiring that any remote Perforce services with which yours is configured to communicate have valid login tickets for your installation. Service users do not consume Perforce licenses.

A service user can run only the following commands:

To create a service user, run the command:

p4 user -f service1

The standard user form is displayed. Enter a new line to set the new user's Type: to be service; for example::

User:      service1
Email:     [email protected]
FullName:  Service User for remote depots
Type:      service

By default, the output of p4 users omits service users. To include service users, run p4 users -a.

Group:            service_users
Timeout:          unlimited
PasswordTimeout:  unlimited
Subgroups:
Owners:
Users:
        service1

If files have been left open by a nonexistent or obsolete user (for instance, a departing employee), a Perforce administrator can revert the files by deleting the client workspace specification in which the files were opened.

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

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

you can delete the stlouis client workspace specification with:

p4 client -d -f stlouis

Deleting a client workspace specification automatically reverts all files opened in that workspace, deletes pending changelists associated with the workspace, and any pending fix records associated with the workspace. Deleting a client workspace specification does not affect any files in the workspace actually used by the workspace's owner; the files can still be accessed by other employees.

Over time, a Perforce server accumulates many revisions of files from old projects that are no longer in active use. Because p4 delete merely marks files as deleted in their head revisions, it cannot be used to free up disk space on the server.

Archive depots are a solution to this problem. You use archive depots to move infrequently-accessed files to bulk storage. To create one, mount a suitable filesystem, and use the p4 archive (and related p4 restore) commands to populate an archive depot located on this storage.

Archiving is restricted to files that meet all of the following criteria:

To create an archive depot and archive files to it:

Disk space is freed up on the (presumably high-performance) storage used for your local depot, and users can no longer access the contents of the archived files, but all file history is preserved.

To restore files from an archive depot:

To purge data from an archive depot

Occasionally, users accidentally add files (or entire directory trees) to the wrong areas of the depot by means of an inadvertent branch or submit. There may also be situations that require that projects not only be removed from a depot, but the history of development work be removed with it. These are the situations in which p4 obliterate can be useful.

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.

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

Revision ranges are also acceptable. To destroy revisions 5 through 7 of a file, use:

p4 obliterate -y file#5,7

You can use the -o flag to the p4 unload command to unload a client, label, or task stream to a flat file on the client rather than to a file in the unload depot. This can be useful for seeding a client into another database or for creating a private backup of the client. The flat file uses standard journal format. The client, label, or task stream remains fully loaded after the command is run.

Perforce administrators can use the -f (force) flag with p4 change to change the description, date, or user name of a submitted changelist. The syntax is p4 change -f changenumber. This command presents the standard changelist form, but also enables superusers to edit the changelist's time, description, date, and associated user name.

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.

Perforce administrators can use the p4 verify filenames command to validate stored MD5 digests of each revision of the named files. The signatures created when users store files in the depot 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. If a new signature does not match the signature in the Perforce database for that file revision, Perforce displays the characters BAD! after the 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. The server is also under heavy load while files are being verified, which can impact the performance of other Perforce commands. 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.

Perforce uses the filesys.binaryscan configurable to determine how many bytes to examine when determining if a file is of type text or binary. By default, filesys.binaryscan is 65536; if the high bit is clear in the first 65536 bytes, Perforce assumes it to be text; otherwise, it is assumed to be binary. Files compressed in the .zip format (including .jar files) are also automatically detected and assigned the type ubinary.

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 application. For example, to treat all PDF and RTF files as binary, use p4 typemap to modify the typemap table as follows:

Typemap:
        binary //....pdf
        binary //....rtf

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.

# Perforce File Type Mapping Specifications.
#
#  TypeMap:     a list of filetype mappings; one per line.
#               Each line has two elements:
#               Filetype: The filetype to use on 'p4 add'.
#               Path:     File pattern which will use this filetype.
# See 'p4 help typemap' for more information.
TypeMap:

        text //....asp
        binary+F //....avi
        binary //....bmp
        binary //....btr
        text //....cnf
        text //....css
        binary //....doc
        binary //....dot
        binary+w //....exp
        binary+F //....gif
        binary+F //....gz
        text //....htm
        text //....html
        binary //....ico
        text //....inc
        text+w //....ini
        binary //....jpg
        text //....js
        binary+w //....lib
        text+w //....log
        binary+F //....mpg
        binary //....pdf
        text+w //....pdm
        binary //....ppt
        binary //....xls

If a file type requires the use of more than one file type modifier, specify the modifiers consecutively. For example, binary+lFS10 refers to a binary file with exclusive-open (l), stored in full (F) rather than compressed, and for which only the most recent ten revisions are stored (S10).

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

By default, Perforce supports concurrent development, but environments in which only one person is expected to have a file open for edit at a time can implement pessimistic locking by using the +l (exclusive open) modifier as a partial filetype. If you use the following typemap, the +l modifier is automatically applied to all newly added files in the depot:

Typemap:
        +l //depot/...

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.

Certain commands support the -f flag, which enables Perforce administrators and superusers to force certain operations unavailable to ordinary users. Perforce administrators can use this flag with p4 branch, p4 change, p4 client, p4 job, p4 label, and p4 unlock. Perforce superusers can also use it to override the p4 user command. The usages and meanings of this flag are as follows.

With the addition of SSL support in 2012.1, there is no longer a need to manually configure an ssh or other VPN tunnel in order to run Perforce securely over an untrusted communication channel.

Under most circumstances, your Perforce server's P4PORT setting consists of a protocol and a port number. Users must know the IP address (or be able to resolve it from a hostname) of the Perforce server in order to connect to it.

If you specify a protocol, an IP address and a port number in P4PORT to the p4d process, the Perforce server ignores requests from any IP addresses other than the one specified in P4PORT. This configuration is useful if you need to configure p4d to listen only to a specific network interface or IP address; you can force your Perforce server to ignore all non-local connection requests by setting P4PORT==protocol:localhost:port.

Under a normal installation, the Perforce service runs on UNIX as a background process that waits for connections from users. To have p4d start up only when connections are made to it, using inetd and p4d -i, add the following line to /etc/inetd.conf:

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

and then add the following line to /etc/services:

p4dservice nnnn /tcp

where:

The "extra" p4d on the /etc/inetd.conf line must be present; inetd passes this to the OS as argv[0]. The first argument, then, is the -i flag, which causes p4d not to run in the background as a daemon, but rather to serve the single client connected to it on stdin/stdout. (This is the convention used for services started by inetd.)

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:

Very early (pre-97.2) releases of the Perforce server treated all filenames, pathnames, and database entity names with case significance, whether the server was running on UNIX or Windows.

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 following table summarizes these rules.

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

Use the p4 monitor command to observe and control Perforce-related processes running on your Perforce server machine.

To list the processes monitored by the Perforce server, use the command:

p4 monitor show

To restrict the display to processes currently in the running state, use the command:

p4 monitor show -s R

By default, each line of p4 monitor output looks like this:

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

where pid is the UNIX process ID (or Windows thread ID), status is R or T depending on whether the process is running or marked for termination, owner is the Perforce user name of the user who invoked the command, hh:mm:ss is the time elapsed since the command was called, and command and args are the command and arguments as received by the Perforce server. For example:

$ p4 monitor show
74612 R qatool     00:00:47 job
78143 R edk        00:00:01 filelog
78207 R p4admin    00:00:00 monitor

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

$ p4 monitor show -a
74612 R qatool     00:00:48 job job004836
78143 R edk        00:00:02 filelog //depot/main/src/proj/file1.c //dep
78208 R p4admin    00:00:00 monitor show -a

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]

where client is the Perforce application (and version string or API protocol level), IP-address is the IP address of the user's Perforce application, and workspace is the name of the calling user's current client workspace setting. For example:

$ p4 monitor show -e
74612 p4/2011.1 192.168.10.2   R qatool    buildenvir 00:00:47 job
78143           192.168.10.4   R edk       eds_elm    00:00:01 filelog
78207 p4/2011.1 192.168.10.10  R p4admin   p4server   00:00:00 monitor

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:

$ p4 monitor show -a -l
74612 R qatool     00:00:50 job job004836
78143 R edk        00:00:04 filelog //depot/main/src/proj/file1.c //dep
ot/main/src/proj/file1.mpg
78209 R p4admin    00:00:00 monitor show -a -l

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

To modify the behavior of command tracing or performance tracking, specify the appropriate -v subsystem=value flag to the p4d startup command. Use P4LOG or the -L logfile flag to specify the log file. For example:

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

Before you activate logging, make sure that you have adequate disk space.

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.

Higher levels of the Perforce server command tracing and tracking flags are typically recommended only for system administrators working with Perforce Technical Support to diagnose or investigate problems.

The Perforce Server is capable of logging individual file accesses to an audit logfile. 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:

$ tail -2 auditlog
2011/05/09 09:52:45 karl@nail 192.168.0.12 diff //depot/src/x.c#1
2011/05/09 09:54:13 jim@stone 127.0.0.1 sync //depot/inc/file.h#1

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

If you are auditing server activity in a replicated environment, each of your build farm or forwarding replica servers must have its own P4AUDIT log set.

As of Release 2012.1, the Perforce Server can now be configured to write log files in a structured(.csv) format. Structured log files contain more detail than the conventional log files, are easier to parse, and the Perforce Server offers additional commands to help customize your site's logging configuration:

If the architecture of the two machines uses the same byte order (for example, SPARC/SPARC, x86/x86, or even 32-bit Windows to 64-bit Windows), 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).

(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.)

If the internal data representation (big-endian vs. little-endian) convention differs between the two machines (for example, Linux-on-x86/SPARC), but their operating systems use the same CR/LF text file conventions, you can still simply move the server root directory tree to the new machine.

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

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

In this case, both the architecture of the system and the CR/LF text file convention may be different. You still have to create a checkpoint, copy it, and re-create the database on the new platform, but when you move the depot subdirectories containing your versioned files, you also have to address the issue of the differing linefeed convention between the two platforms.

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.

If the IP address of the new machine is not the same as that of the old machine, you will need to update any IP-address-based protections in your protections table. See Administering Perforce: Protections for information on setting protections for your Perforce 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.

If the hostname of the new machine serving Perforce is different from that of its predecessor, your users must change their P4PORT settings. If the old machine is being retired or renamed, consider setting an alias for the new machine to match that of the old machine, so that your users won't have to change their P4PORT settings.

Depot names share the same namespace as branches, client workspaces, and labels. For example, //rel2 refers uniquely to one of the depot rel2, the workspace rel2, the branch rel2, or the label rel2; you can't simultaneously have both a depot and a label named rel2.

To define a new local depot (that is, to create a new depot in the current Perforce server namespace), call p4 depot with the new depot name, and edit only the Map: field in the resulting form.

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:

Depot:       book
Type:        local
Address:     local
Suffix:      .p4s
Map:         book/...

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.

In order for your users to retrieve change histories of user-edited forms, you must enable versioned specifications. The spec depot can have any name, but it must be of type spec, and there can only be one spec depot per server. (If you already have a spec depot, attempting to create another one results in an error message.)

After you have enabled versioned specs by creating the spec depot, all user-generated forms (such as client workspace specifications, jobs, branch mappings, 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]]

Some formtypes (for example, the protect, triggers, and typemap forms) are unique to the server, and do not have corresponding objectnames.

Depot:       spec
Type:        spec
Address:     local
Map:         spec/...
SpecMap:     //spec/...
Suffix:      .p4s

SpecMap:
    //spec/...
    -//spec/protect

SpecMap:
    //spec/...
    -//spec/client/build_ws_*
    -//spec/label/temp_label_*

To list all depots known to the current Perforce server, use the p4 depots command.

To delete a depot, use p4 depot -d depotname.

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

In a distributed environment, the unload depot may have different contents on each edge server. Since the commit server does not verify that the unload depot is empty on every edge server, you must specify p4 depot -d -f in order to delete the unload depot from the commit server. For more information, see Distributing Perforce.

Perforce is designed to cope with the latencies of large networks and inherently supports users with client workspaces at remote sites. A single Perforce installation is ready, out of the box, to support a shared development project, regardless of the geographic distribution of its contributors.

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 better to set up a distributed Perforce installation. For information on setting up and monitoring a distributed Perforce configuration, see the Distributed Perforce manual.

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.

The following diagram illustrates how Perforce applications use a user's default Perforce server to access files in a depot hosted on another Perforce server.

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.

Performing a code drop requires coordination between two organizations, namely the site receiving the code drop and the site providing the code drop. In most cases, the following three things must be configured:

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

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

list user remote * -//...
read user remote 192.168.41.2 //depot/outbound/...

The Perforce server can be run in Unicode mode to activate support for:

In Unicode mode, the Perforce server also translates unicode files and metadata to the character set configured on the user's machine, and verifies that the unicode files and metadata contain valid UTF-8 characters.

To configure a Unicode-mode server and the workstations that access it, you must:

The following sections tell you how to configure Perforce to manage such files.

To enable the Perforce server to manage files and directories with names that include Unicode characters, you must configure your server to run in Unicode mode. In Unicode mode, the server:

To correctly interoperate with Unicode-mode servers, you must configure user workstations by setting the P4CHARSET environment variable. Recommendation: use separate workspaces for connections that require different character sets.

If a user connects to a new Perforce service, performance-related properties are reloaded for the Perforce service to which the user has most recently connected.

You can use the following properties to enable or disable P4V features. These properties are read once, upon P4V startup, from the first service to which the user connects. Features that are deactivated by setting these properties to Off are unavailable in P4V and do not display in P4V's Preferences page:

For example, the administrator of a site that does not use Perforce's built-in defect tracking can disable access to jobs from within P4V by running:

p4 property -a -n P4V.Features.Jobs -v Off

A new property is added/updated (-a), it is named (-n) P4V.Features.Jobs, and it is assigned the value (-v) of Off.

If one group of users within the organization has a need to use the jobs functionality of P4V, the feature can be selectively (and centrally) re-enabled for those users with:

p4 property -a -n P4V.Features.Jobs -v On -g jobusers

The jobs feature of P4V is re-enabled by setting its value to On, but only for users in the jobusers group.

You can use the P4.Combine.URL property to enable the rich comparison of Microsoft Word .doxc files through P4Merge. You must deploy P4Combine as part of a Commons deployment to use this feature.

To enable the feature, set the P4.Combine.URL server property to the P4Combine Web Service URL. P4V will then display a rich compare of .docx files in the P4Merge window, using HTML5 to show differences for text, images, formats, styles, tables, headers, footers, and other objects.