Perforce Merging Process

Perforce Merging Process
In Perforce when we have conflict in files, “?” notion comes with the files which says this need to be resolved. Once you select the file and click on Resolve, it will be given following options…

1. Accept Changed file (Only one files differs from the base
2. Merge yours and theirs if no conflict exists
3. Accept yours
4. Accept theirs
5. Merge yours and theirs including conflict markers

Interactive – Interactively resolve files one at a time
Let’s try to first resolve the conflict with Auto options but if the conflict is not resolved then try to use interactive option which gives greater flexibility to resolved the conflict and submit the changes.

Tagged : / / /

Basic Perforce Administration

A. User maintenance tasks

1. Resetting passwords
2. Creating users / Deleting users / Setting user access
3. Disabling the automatic creation of users
4. Cleaning up files left open by former users

B. Administrative operations

1. Setting the server security level
2. Obliterating files to reclaim disk space
3. Editing submitted changelists
4. Verifying server integrity
5. Defining files types to control Perforce’s file type detection mechanism
6. Use of the -f flag to force operation

In perforce, There are 2 Types of authentication menthods.
1. passwords
2. tickets

Login to Perforce
> p4 login

Logout to the perforce
> p4 logout

Server security levels

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

> p4 counter -f security seclevel

where seclevel is 0, 1, 2, or 3. After setting the counter, stop and restart the server.

  • The default security level is 0: passwords are not required, and password strength is not enforced.
  • To ensure that all users have passwords, use security level 1. Users of old client programs may still enter weak passwords.
  • To ensure that all users have strong passwords, use security level 2.
  • 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.

Resetting user passwords

> p4 passwd username

Creating users

> p4 user -f username

Preventing creation of users

1. Create a New p4 group or existing groups
> p4 group p4users
2. Set P4 access to that Groups using
> p4 protect
and add following..
write group p4users * //…

Deleting obsolete users
> p4 user -d -f username

Reverting files left open by obsolete users

For example, if the output of p4 opened shows:
//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, and also removes that workspace’s “have list”.

Running from inetd on UNIX

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 -rp4droot

and add the following to /etc/services:

> 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

Tagged : / /

Recovery Procedures in Perforce Server

Recovery Procedures in Perforce Server

If the database files become corrupted or lost, either because of disk errors, a hardware failure such as a disk crash, the database can be recreated with your stored checkpoint and journal. it can at least provide a general guideline for recovery from the two most common situations, specifically:

1. corruption of your Perforce database only, without damage to your versioned files, and
2. corruption to both your database and versioned files.

Case 1: Database corruption, versioned files unaffected

You will need:
1. The last checkpoint file, which should be available from the latest P4ROOT directory backup.

2. The current journal file, which should be on a separate filesystem from your P4ROOT directory, and which should therefore have been unaffected by any damage to the filesystem where your P4ROOT directory was held.

You will not need:
1. Your backup of your versioned files; if they weren’t affected by the crash, they’re already up to date.

To recover the database

1. Stop the current instance of p4d:

p4 admin stop

(You must be a Perforce superuser to use p4 admin.)

2. Rename (or move) the database (“db.*”) files:

mv your_root_dir/db.* /tmp

There can be no db.* files in the $P4ROOT directory when you start recovery from a checkpoint. Although the old db.* files are never used during recovery, it’s good practice not to delete them until you’re certain your restoration was successful.

3. Invoke p4d with the -jr (journal-restore) flag, specifying your most recent checkpoint and current journal. If you explicitly specify the server root ($P4ROOT), the -r $P4ROOT argument must precede the -jr flag:

p4d -r $P4ROOT -jr checkpoint_file journal_file

This recovers the database as it existed when the last checkpoint was taken, and then apply the changes recorded in the journal file since the checkpoint was taken.

Case 2: Both database and versioned files lost or damaged

You will need:
1. The last checkpoint file, which should be available from the latest P4ROOT directory backup.
2. Your versioned files, which should be available from the latest P4ROOT directory backup.

You will not need:

Your current journal file. The journal contains a record of changes to the metadata and versioned files that occurred between the last backup and the crash; because you’ll be restoring a set of versioned files from a backup taken before that crash, the checkpoint alone contains the metadata useful for the recovery, and the information in the journal is of limited or no use.

To recover the database

1. Stop the current instance of p4d:

p4 admin stop
(You must be a Perforce superuser to use p4 admin.)

2. Rename (or move) the corrupt database (“db.”) files:
mv your_root_dir/db.* /tmp

The corrupt db.* files aren’t actually used in the restoration process, but it’s safe practice not to delete them until you’re certain your restoration was successful.

3. Invoke p4d with the -jr (journal-restore) flag, specifying only your most recent checkpoint:

p4d -r $P4ROOT -jr checkpoint_file

Some Tips While Setting up Perforce Server Configuration to have best Backup & Recovery methodlogy

1. Make sure you are using Symbolic Links for storing versioned files in another drive
2. Make sure you are Storing Journal files in differnet directory
2. Make sure you are storing check points in different directory

Tagged : / / /

How to Backup Perforce Server

How to Backup Perforce Server

Regular backups of your Perforce data are vital. The key concepts are:

  • Make sure journaling is active
  • Create checkpoints regularly, and
  • Use p4 verify regularly
  • Versioned files

checkpoint is a snapshot or copy of the database at a particular moment in time.

journal is a log that records updates made to the database since the last snapshot was taken.

How to Make sure journaling is active

For UNIX installations, journaling is also automatically enabled. If P4JOURNAL is left unset (and no location is specified on the command line), the default location for the journal is $P4ROOT/journal.

How to create a checkpoints

To create a checkpoint, invoke the p4d program with the -jc (journal-create) flag:

p4d -r root -jc

You can create a checkpoint while the Perforce server (p4d) is running. The checkpoint is created in your server root directory (P4ROOT).

To make the checkpoint, p4d locks the database and then dumps its contents to a file named checkpoint.n in the P4ROOT directory, where n is a sequence number.

To create a checkpoint without being logged in to the machine running the Perforce server, use the command:

p4 admin checkpoint [-z] [prefix]

Versioned files

Your checkpoint and journal files are used to reconstruct the Perforce database files only. Your versioned files are stored in directories under the Perforce server root, and must be backed up separately.

Backup Procedures

1. Verify the integrity of your server and add MD5 digests and file length metadata to any new files:

p4 verify //…

You may wish to pass the -q (quiet) option to p4 verify. If called with the -q option, p4 verify produces output only when errors are detected.

2. Make a checkpoint by invoking p4d with the -jc (journal-create) flag, or by using the p4 admin command. Use one of:

p4d -jc
p4 admin checkpoint

3. Ensure that the checkpoint has been created successfully before backing up any files. (After a disk crash, the last thing you want to discover is that the checkpoints you’ve been backing up for the past three weeks were incomplete!) You can tell that the checkpoint command has completed successfully by examining the error code returned from p4d -jc, or by observing the truncation of the current journal file.

4. Once the checkpoint has been created successfully, back up the checkpoint file, the old journal file, and your versioned files.


  • Use separate physical drives for server root and journal
  • Use protections and passwords: Until you define a Perforce superuser, every Perforce user is a Perforce superuser, and can run any Perforce command on any file. After starting a new Perforce server, use:> p4 protect and To set (or reset) a user’s password, use p4 passwd username (as a Perforce superuser),
  • Allocate disk space for anticipated growth
Tagged : / / /

Perforce Server Installation and Configuration

p4d – Perforce Server
p4 – Perforce Client
p4win – Perforce Windows Client

Install P4 Server in Unix

  • Copy p4d & p4 in /usr/local/bin
  • Give permission such as chmod +x p4 & chmod +xp4d
  • Create Perforce ROOT directory such as P4ROOT=/usr/local/p4_directory
  • Give permission to P4 root directory and sub directory
  • Tell perforce server to use which port such as P4PORT=servername:1666 or p4d -p 1666
  • Startting Server with Command Line Setup. p4d -r /usr/local/p4root -J /var/log/journal -L /var/log/p4err -p 1666 &
  • Tellin perforce client to which port to listen such as p4_server_hostname:1666
  • Stopping Server e.g. p4 admin stop
Tagged : / / /

Syncing missing/modified files to a specific version in Perforce

I think this is the 5th time I’ve had to figure this out in the past few years, so this time I’m going to preserve it here for posterity :)

The problem is usually one or more of:

  • You have files missing from your workspace that need replaced.
  • You have locally modified (i.e. not opened for edit) files that need replaced.
  • These files are large in either size or number, and on a slow or remote server, so a complete force-sync is not an appealing option.

Normally this could easily be solved with something like p4 diff -sd/-se //depot/path/.. | p4 -x – sync -f, which finds all the missing/outdated files and then force-syncs them.

The problem with this approach comes when you need the files from a specific revision or label. While you can pass in a label/revision to ‘p4 diff’, the sync part will always retrieve the latest version of a file. To fix this we need to save the list of files we need to a temporary location, then postfix each line with the version we want, then feed that new list back to p4 sync.

But there’s one final catch. If your filenames are local paths instead of Perforce paths, you cannot specify a label, only revisions. E.g. c:\temp\foo.dat@SOME_LABEL will not work, but c:\temp\foo.dat#999 will. Fortunately we can use the pseudo revision ‘have’ for our purposes.

@echo off

REM Could optionally pass these as %1 and %2 from the cmd line
set BASE_DIR=//depot/path/…

del p4sync.txt

echo Setting ‘have’ to %LABEL% for %BASE_DIR%
REM do a nop sync that sets our ‘have’ version to the label we want
p4 sync -k %BASE_DIR%%LABEL%

echo Finding modified files..
p4 diff -se %BASE_DIR%%LABEL% > p4diff.txt

echo Finding missing files..
p4 diff -sd %BASE_DIR%%LABEL% >> p4diff.txt

echo Building sync commands
REM Append #have to each filename and put them all in a list of files to sync
for /f %%i in (p4diff.txt) Do echo %%i#have>> p4sync.txt

REM Now sync everything
if exist p4sync.txt (
echo Syncing..
p4 -x p4sync.txt sync -f
)else (
echo It seems no files need updated!


Tagged : / / / / / /

Changing the case of folder name on Perforce.

scmuser created the topic: Changing the case of folder name on Perforce.
I want to change the name of folder //depot/licensing/… on perforce server to
//depot/licensing/… but perforce is not allowing me to do the same.

P4 submit fails with the “PreventCaseDiffs validation failed” error.
Could you please tell me how can I do it or it’s just the super user who can do this change.

Tagged :

Determining the last changelist synced to in Perforce

rajeshkumar created the topic: Determining the last changelist synced to in Perforce
7 down vote accepted

The simple answer is:

p4 changes -l “…#>have”

You need the quotes to avoid your shell doing redirection.

You can trivially iterate over the changes and call “p4 describe” on each one.

You can get a full diff by using “p4 diff2” (assuming you want a unidiff):

p4 diff2 -du …#have …#head

But that doesn’t give you a per-changelist diff.…c-directory-by-non-l…ynced-to-in-perforce…elist-of-a-Workspace
Rajesh Kumar
Twitt me @

Tagged :

Step by Step Instruction to Upgrade Perforce to 2014


Step by Step Instruction to Upgrade Perforce to 2014

The step are as follows:

a) Check if the license is current.

p4 license -o

The expiry date must be later than the binary release date you are installing

b) Verify server archives using the command ‘p4 verify -q //… > verify.txt’

* Note – If the file ‘verify.txt’ contains a ‘BAD!’ or MISSING!’
signature during the verify command, please contact Perforce Support prior to upgrading.
** If the depot is large and you get an error message “Request too large for server memory”, you can split the verify to check chink of the depot:

p4 verify -q //depot/project1/… > prj1-verify.txt
p4 verify -q //depot/project2/… > prj2-verify.txt
p4 verify -q //depot/project3/… > prj3-verify.txt

c) Stop the Perforce Server.

p4 admin stop

d) Make a checkpoint of the database.

p4d -r P4ROOT -J journal -jc

e) Copy the db.* files to a safe location.

f) Backup your archive files.

g) Read the release notes so you are aware of the latest changes.

h) Download the latest P4D version.

i) Verify that the newly downloaded binary is the latest. You might need to copy the p4d.exe to p4s.exe

p4d.exe -V
p4s.exe -V

j) Install the upgraded version of the Perforce server.

k) Restore the Perforce Server using the new P4D Binary and the checkpoint taken from the old P4D binary, with the following command ‘p4d –r root –jr’.

l) If the server contains more than 1000 changelists, please run the following command ‘p4d -r root -xu’ from the command line’.

m) Start the perforce Sever.

n) Verify server archive files.

p4 verify -q //… > upgrade-verify.txt

** Note – If the file ‘upgrade-verify.txt’ will contains a ‘BAD!’ or MISSING!’ signature during the verify command, please contact us.

o) Take a checkpoint
p4d -r root -J journal -jc

This is also explained in the below article:

Upgrading to 2013.3 and beyond –

Windows To Linux
Moving from Linux to Windows is not a trivial issue, and such a migration is also not supported and will most likely require consolidation of case sensitivity conflicts using our P4 Migrate product. Please see the link below:

Cross-Server Platform Migration

Change of Server is a “Self-serve” option, please fill out this form and licensing will update accordingly.
P4 Support Change of Server License Request

Please pass the -z switch during the replay as the checkpoint/journal you are replaying are compressed:
p4d -r P4ROOT -jr -z checkpoint.ckp.104.gz

You will need to request for a background user I believe to be able to do all the required command. This can be done by filling in this below form and using one background user for all of you build machines.

Moving a Perforce Server

 By Chris Lesemann <

Our Knowledge Base has accurate and up to date information that will help you prepare your own procedure for upgrading. Because the database structures have changed, you will need to take an existing checkpoint and then replay that checkpoint with the 2014.1 version of the P4 Server.

It appear you are on a 32-bit Windows instance…will you be doing an inplace upgrade or moving to 64-bit hardware? If you are moving from 32-bit to -64bit you have to recover from checkpoint anyway.

Please review the two links below and if you have any further questions I would be happy to assist you:

 Upgrading to 2013.3 and beyond <– specific procedure for moving from 2013.2 and earlier P4 to 2013.3 and later

 Upgrading a Perforce Server <– in-place upgrade

 Moving a Perforce Server <– if you have to move to new hard – do NOT start a 64-bit P4D binary against 32-bit db.* databases, or vice versa.

 Upgrading the Perforce Proxy

General information on the new Btree structures and functionality:

 BTree Format Changed for Perforce Server Versions 2013.3 and Later

 Lockless Reads

Tagged : / / / / / / / / / / / / / / / / /

Ways to Perforce server Disk Space Cleanup and Repos Size Management



  1. Cleaning up Old Checkpoints
  2. Playing with Symlink(Softlink) and Redirecting the ROOT folder to drive where we have enough place.
  3. Deleting db.have and recreate it manually
  4. Display disk space information on the server using “p4 diskspace”
  5. Display size information for files in the depot using “p4 sizes”
Tagged : / / / / / / / / / / / / / / / / /