Perforce install

The choice depends on network topology, the geographic distribution of work, and the relationships among the files being managed. If multiple servers are run, assign each instance a number and use that number as part of the name assigned to depots, to make the relationship of depots and servers obvious. See the discussion above on Instance Names. In this section we describe the server and SDP installation process on Windows. The process consists of:. GOW Gnu on Windows - optional but very useful for parsing log files etc.

The scripts now use Powershell rather than. BAT files due to improved error handling and options, and code re-use via a single included module rather than duplication of functionality in every script.

This also allows us to keep the scripts more closely aligned with the functionality of the Unix scripts. It is important to enable local scripts to be run. The following command must be run within an Powershell Administrator prompt:. The result needs to be either RemoteSigned or Unrestricted. If not then set it as below. Use get-executionpolicy to check the policy has been updated.

You may need to ensure that the various scripts are not "blocked" - right click in Windows Explorer and check Properties options. Mount the volumes for the three-volume configuration described in Volume Layout and Hardware.

The procedure assumes the drives are mapped as follows:. Customize the following for your environment. It requires you to identify the master server and all replicas that we need to setup for the SDP, including instance names, hostnames, etc.

This information is all in a single file:. Download and install Python, e. We use Python 2. Typically we install to default dir, e.

For initial installation we only require base Python. For subsequent scripting you may wish to install P4Python e. These are recommended but not strictly required. For example, for Helix Core for release From that directory listing, select p4. If you are using 32 bit Windows unusual these days , substitute bin. The following works within Powershell. It creates. It contains lots of comments as to how to set the various configuration values. This file will be parsed and used to create instance specific configuration files.

If the output looks correct then re-run the script with -y parameter to actually perform the copying of files and creation of directories and links. The above command will create a couple of files in that directory. Validate the contents of this file and run it if it looks appropriate - this installs the service s with appropriate parameters. It should look something like:.

If the service fails to start, then examine the log file for the reason e. Desktop shortcuts simplify setting up the SDP shell environment, making it easy to interact with the configured Helix Core service.

The shortcut brings up a Windows Command Prompt cmd. For example, if the instance name is 1 the default , create a shortcut named P4Admin 1.

It should have these contents:. The Create Shortcut dialog will come up prompting: Type the location of the item:. In the text box, enter:. Then when it prompts Type a name for this shortcut: , enter:. Next, right-click on the new shortcut, and click Properties. On the P4Admin Properties dialog, click the Advanced button. You will only be able to run the. If an instance is a replica or similar , then you should apply the configurables to the master server and then checkpoint it before seeding the replica - see the Distributing Perforce guide.

Then add the following to the Protections table, near the bottom about super user entries , to hide specs which could have security implications:. To delete the default Perforce depot named depot, issue the following command: p4 depot -d depot. Issue the p4 info command, after setting appropriate environment variables. If the server is running, it will display details about its settings. In Windows or later you should use the Task Scheduler.

We recommend that you create a folder called Perforce at the top level in which to create your tasks otherwise they can be hard to find when you next look in Task scheduler! Note that the schtasks command can be useful from command line, or taskschd. This prevents log files getting too big. These are all setup in a similar way to the screenshots below Section 3. A typical workspace view e. You would have appropriate workspaces for each machine, and appropriate lines for each instance on that machine.

Now that the server is running properly, copy the following configuration files to the depotdata volume for backup:. Adjust the depot root paths with Older versions of the Windows SDP pre June stored configuration values for each instance in a p4env. Extract existing values from p4env. Using a different but similar workspace p4admin.

In workspace p4admin. Validate that the daily backup works typically wait until the next day. After the server is installed and configured, most sites will want to modify server permissions protections and security settings.

Other common configuration steps include modifying the file type map and enabling process monitoring. To configure permissions, perform the following steps:. Define protections for your server using groups. Perforce uses an inclusionary model. It is best for performance to grant users specific access to the areas of the depot that they need rather than granting everyone open access, and then trying to remove access via exclusionary mappings in the protect table even if that means you end up generating a larger protect table.

For already-compressed file types such as. For large, generated text files e. This section presents an overview of the SDP scripts and tools. Details about the specific scripts are provided in later sections. Then, use the p4. Take a checkpoint of the live database on instance 1. Perforce servers maintain metadata and versioned files. The metadata contains all the information about the files in the depots.

Metadata resides in database db. The versioned files contain the file changes that have been submitted to the server. Versioned files reside on the depotdata volume. This section assumes that you understand the basics of Perforce backup and recovery. The weekly sequence is described below. See also Section 3. Replay the journal to the offline database.

Refer to Figure 2: Volume Layout for more information on the location of the live and offline databases. This normal maintenance procedure puts the checkpoints metadata snapshots on the depotdata volume, which contains the versioned files.

Backing up the depotdata volume with a normal backup utility like robocopy or rsync provides you with all the data necessary to recreate the server. To ensure that the backup does not interfere with the metadata backups checkpoints , coordinate backup of the depotdata volume using the SDP maintenance scripts.

The preceding maintenance procedure minimizes server downtime, because checkpoints are created from offline or saved databases while the server is running.

When you have server specs with Services field set to commit-server , standard , or edge-server - see deployment architectures you should consider your requirements for how to recover from a failure to any such servers.

The key issues are around ensuring that you have have appropriate values for the following measures for your Helix Core installation:. RPO - Recovery Point Objective - how much data are you prepared to risk losing if you have to failover to a backup server?

We need to consider planned vs unplanned failover. Planned may be due to upgrading the core Operating System or some other dependency in your infrastructure, or a similar activity. So, if your main commit-server fails, how fast should be you be able to be up and running again, and how much data might you be prepared to lose? What is the potential disruption to your organisation if the Helix Core repository is down?

How many people would be impacted in some way? You also need to consider the costs of your mitigation strategies. For example, this can range from:. Thus you might lose up to 24 hours of work for an unplanned failure, and require several hours to restore. An HA replica is close to its upstream server, e.

A DR replica is in a more remote location, so maybe risks being further behind in replication thus higher RPO , but mitigates against catastrophic loss of a data center or similar. Note that "further behind" is still typically seconds for metadata, but can be minutes for submits with many GB of files. A commit server instance is the ultimate store for submitted data, and also for any workspace state WIP - work in progress for users directly working with the commit server part of the same "data set".

An edge server instance maintains its own copy of workspace state WIP. If you have people connecting to an edge server, then any workspaces they create and files they open for some action will be only stored on the edge server. There is a concept of a "build edge" which is an edge server which only supports build farm users. In this scenario it may be deemed acceptable to not have an HA backup server, since in the case of failure of the edge, it can be re-seeded from the commit server.

All build farm clients would be recreated from scratch so there would be no problems. As of Such a replica performs a journalcopy replication of metadata, with a local pull thread to update its db. See also: Configuring a Helix Core Standby. You can modify the server spec of a standby replica to make it mandatory. This can simplify failover, since it provides a guarantee that no downstream servers are ahead of the replica. Thus downstream servers can simply be re-directed to point to the standby and will carry on working without problems.

If set to nomandatory then there is no risk of delaying downstream replicas, however there is equally no guarantee that they will be able to switch seamlessly over to the new server. Use a name that does not indicate switchable roles, e. This might otherwise lead to confusion once you have performed a failover and the host name is no longer appropriate.

Use names ending numeric designators, e. The goal is to avoid being in a post-failover situation where a machine with master or primary is actually the backup. Also, the assumption is that host names will never need to change.

If used, use the same site tag used in the ServerID, e. This is based on the idea that when the major OS is upgraded, you either move to new hardware, or change the host name an exception to the rule above about never changing the hostname. This option maybe overkill for many sites.

For edge servers, it is advisable to include edge in both the host and DNS name, as users and admins needs to be aware of the functional differences due to a server being an edge server. Your commit or standard server has a license file tied to IP address , while your replicas do not require one to function as replicas. However, in order for a replica to function as a replacement for a commit or standard server, it must have a suitable license installed. This should be requested when the replica is first created.

Perforce supports a full one-way replication of data from a master server to a replica, including versioned files. The p4 pull command is the replication mechanism, and a replica server can be configured to know it is a replica and use the replication command.

The p4 pull mechanism requires very little configuration and no additional scripting. As this replication mechanism is simple and effective, we recommend it as the preferred replication technique.

Replica servers can also be configured to only contain metadata, which can be useful for reporting or offline checkpointing purposes. See the Distributing Perforce Guide for details on setting up replica servers. If you wish to use the replica as a read-only server, you can use the P4Broker to direct read-only commands to the replica or you can use a forwarding replica.

The broker can do load balancing to a pool of replicas if you need more than one replica to handle your load. Once the machine and SDP install is in place, you need to configure the master server for replication. We always recommend first setting up the replica as a read-only replica and ensuring that everything is working.

Once that is the case you can easily modify server specs and configurables to change it to a forwarding replica, or an edge server etc. To set this up, run the following on both the master and the replica:. We will assume the following for the setup:. You will run the following commands on the master server:. Now that the settings are in the master server, you need to create a checkpoint to seed the replica.

When the checkpoint finishes, copy the checkpoint plus the versioned files over to the replica server. You can use xcopy or something like robocopy for this step. If you see those entries, then you can make some changes on the master server, and then go to the replica server and check to see that they changes were replicated across. For example, you can submit a change to the master server, then go to the replica server and check to see that the change was replicated over to the replica by running p4 describe on the changelist against the replica server.

The final steps for setting up the replica server are to set up the task scheduler to run the replica sync scripts. This has to be done via task scheduler running as a regular AD user so that the scripts can access the network in order to get to the drives on the replica machine. The task should be set up to run after the master server finishes running daily-backup.

Be sure to give it some buffer for the length of time it takes the master to run that script is likely to become gradually longer over time. To replay the transactions that occurred after the checkpoint was created, issue the following command:. If problems are reported when you attempt to recover from the most recent checkpoint, try recovering from the preceding checkpoint and journal. If you are successful, replay the subsequent journal.

If the journals are corrupted, contact Perforce Technical Support. This section describes how to recover from a tape or other offline backup to a new server machine if the server machine fails. The tape backup for the server is made from the depotdata volume. In other words, the new server must be as identical as possible to the server that failed.

Verify the database and versioned files by running the p4verify script. Contact Perforce Technical Support for assistance in determining if these files are actually corrupt.

This section describes typical maintenance tasks and best practices for administering server machines. The user running the maintenance scripts must have administrative access to Perforce for most activities. All of these scripts can be run from any client machine. Download the new p4 and p4d executables from ftp. Occasionally modifications are made to the Perforce database. For example, server upgrades and some recovery procedures modify the database. When upgrading the server, replaying a journal patch, or performing any activity that modifies the db.

The easiest way to restart the offline checkpoint process is to run the live-checkpoint script after modifying the db. Archiving labels is a best practice for large installations, with hundreds of users and Perforce checkpoints that are gigabytes in size. Smaller sites need not necessarily concern themselves with archiving labels to maintain performance, though doing so will minimize database size if labels are used extensively. To use the p4 unload and p4 reload commands for archiving clients and labels, you must first create an unload depot using the p4 depot command.

After the depot is created, you can use the following command to archive all the clients and labels that have been accessed since the given date:. As a super user, you can reload and unloaded item by adding the -f flag to the reload command as follows:.

That will cause the server to use the unload depot for storing the labels rather than storing them in db. This helps with performance of the server by not increasing the size of the database for label storage. The simplest option is to use create a template client workspace usual name is template. This will mean that all new client workspaces created after that time will have the same options and view, unless otherwise explicitly updated. Then insert an entry in the trigger table like the following:.

The following sections provide some guidelines for maximizing the performance of the Perforce Server, using tools provided by the SDP. More information on this topic can be found in the Knowledge Base. The server does not fully rebalance and compress them during normal operation. To optimize the files, you must checkpoint and restore the server. The weekly checkpoint script used as part of the normal server maintenance automates this task.

To minimize the size of back up files and maximize server performance, minimize the size of the db. The scripts described in Unloading and Reloading labels, Deleting users , and. To prevent large requests from overwhelming the server, you can limit the amount of data and time allowed per query by setting the maxresults, maxscanrows and maxlocktime parameters to the lowest setting that does not interfere with normal daily activities.

These values must be adjusted up as the size of your server and the number of revisions of the files grow. To simplify administration, assign limits to groups rather than individual users.

To prevent users from inadvertently accessing large numbers of files, define their client view to be as narrow as possible, considering the requirements of their work. Similarly, limit users' access in the protections table to the smallest number of directories that are required for them to do their job.

For remote users who need to sync large numbers of files, Perforce offers a proxy server. P4P, the Perforce Proxy, is run on a machine that is on the remote users' local network. The Perforce Proxy caches file revisions, serving them to the remote users and diverting that load from the main server. At large sites with hundreds or thousands of simultaneous users, the P4V data retrieval settings can help prevent P4V requests from impacting server performance. As of the Determine whether you want P4V settings common to all users, or different settings for different groups.

The file contains suggested default values. The available settings are:. The ServerRefresh interval in minutes, which defines how often P4V attempts to get updated information from the server.

If using common settings for all users, proceed with this step; otherwise proceed to the next step. Install the centralsettings file by adding a line to the protections table like:. Skip this step if using common settings for all users. Modify the line that references p4vsettings. Install each copy of centralsettings.

In our example with separate copies for developers and QA, we would use lines like:. Of course, the P4JsApi provides many other valuable features. If you choose to use these features, you can use the same centralsettings files for your groups to enable them. Refer to the P4JsApi manual for details. This section describes the various scripts and files provided as part of the SDP package on Windows.

The scripts are implemented in Powershell , and usually have a simple. Note that for historical reasons there will often be 2 versions of the. In the sub-sections below we refer to the. Please assume the. This script is configured to run seven days a week using the Windows scheduler. These can be rotated into the live database directory on an occasional e. This script verifies the integrity of the depot files. This script is run by Windows scheduler, usually on a weekly basis, e.

Saturday morning. It emails the resulting report - please check for any errors contained. Note restrictions below. See also partner script Section 7. This script recreates offline db from the latest checkpoint found. This script can also be used anytime to create a checkpoint of the live database with above warnings about locking! This command may be required to be run when an error occurs during offline checkpointing.

It restarts the offline checkpoint process from the live database files to bring the offline copy back in sync. If the live checkpoint script fails, contact Perforce Consulting at consulting perforce. Run this script when creating the server and if an error occurs while replaying a journal during the off-line checkpoint process. This script logs the standard superuser account in to the server with their stored password, using the details from Section 3.

Examples of using the p4login. This script recreates an edge server from create-filtered-edge-checkpoint, maintaining local data such as workspaces in edge specific db. Partner script to Section 7. This script can be scheduled to run every few months - it used to be run weekly, but that is no longer best practice since database files are not fragmented as they used to be. It will move the db. This script sends an email with the results of the latest p4 pull -lj. Useful for basic monitoring services.

This script is intended to be run nightly on a replica which may not have any other scheduled tasks running. This script is the main repository of all shared functions used by other scripts. They each source the file and then call individual functions as required. This is not intended by be called directly by the user - just sourced by other scripts. This script is useful for debugging the setup of the sending of emails by the various scripts.

See Section A. This script copies checkpoint files from master to the current replica. The basic steps to set up additional Perforce Server services are as follows:. The installer names this first service " Perforce ". The service named " Perforce " is managed by the installer and should not be changed manually.

These same components are used to install the second Perforce Service. You also need the Perforce Service install application which is named svcinst. This application can be found in the existing Perforce Server root directory.

Should you be running a 32 bit version of the Windows Helix Server then you may need to get the 'svcinst. Note: The p4d. The configuration information for a Perforce Replica or Edge Server is usually stored in the Master Server's configuration. If so, the only the parameters you set would be from the command line to start the replica server:. To check these settings, use p4 set with no variable value pair. Follow the previous steps for creating a second Perforce Windows service with one notable addition: you must specify the Replica Server's name using the P4NAME registry variable.

For example:. If the Perforce Server root directory is on a network mounted device, the Windows service must be created using an administrative user account. This is done using the -r and -u command line flags to the svcinst application.

Note: Perforce does not recommend locating the Perforce database files on a network mounted device due to performance concerns. See " Server Problems on Windows " for more information. The following is the amended command to create the " Perforce2 " service on a network drive. If you have problems running the svcinst command, use the " -d " as the first flag to see more extensive debugging information. The Helix Core Windows installer makes an effort to prevent such a configuration as well.

For additional help on using the Perforce service installer, run svcinst with the -h flag. If you need help or have questions, please contact support perforce. Whether you're looking for self-service resources, product downloads, or how to contact Technical Support, we've got lots of options to get the help you need—fast! Try Free Request Support.

Sign in to ask the community. Helix Core Admin Tasks. Information Blank. Example for creating a second Perforce Windows service The basic steps to set up additional Perforce Server services are as follows: Create a new server root directory for the additional Perforce Helix Core P4D Server. Copy the server executable to the new server root directory. Install your duplicate license file into the new server root directory. Set the P4D environment variables.

These two files are the same and only differ by the file name.