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

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

A 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
or:
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.

Tips:

• 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

The post How to Backup Perforce Server appeared first on scmGalaxy.

DRAFT VERSION

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”

The post Ways to Perforce server Disk Space Cleanup and Repos Size Management appeared first on scmGalaxy.

Perforce Replication

Replication is the duplication of server data from one Perforce Server to another Perforce Server, ideally in real time. You can use replication to:

• A replica server can function as an up-to-date warm standby system, to be used if the master server fails. Such a replica server requires that both server metadata and versioned files are replicated.
• Reduce load and downtime on a primary server by Long-running queries and reports, builds, and checkpoints can be run against a replica server, reducing lock contention.
• Perforce administrators can configure the Perforce Broker to redirect commands to read-only replica servers to balance load efficiently across an arbitrary number of replica servers.

NOTES:

• For checkpoints and some reporting tasks, only metadata needs to be replicated.
• For reporting and builds, replica servers will need access to both metadata and versioned files.
• With the 2010.2 release, the Perforce Server now replication between Perforce servers of both metadata and versioned files.

Limitation:

• Replication is unidrectional, and replica servers are intended for read-only purposes
• Bidirectional replication is not supported, because any changes made to a replica server can be overwritten by changes made to the master Perforce server.

System Requirement:

• All replica servers must be at the same release level as the master server. Prefebalily 2010.2 to use both command (p4 pull and p4 replicate).
• All replica servers must have the same Unicode setting as the master server.
• All replica servers must be hosted on a filesystem with the same case-sensitivity behavior as the master server’s filesystem.
• All replica servers must be hosted on a filesystem with the same case-sensitivity behavior as the master server’s filesystem
• p4 replicate and p4 pull (when replicating metadata) do not read compressed journals. Therefore, the master server must not compress rotated journals until the replica server has fetched all journal records from older journals
• The master and replica servers must have the same time zone setting.

Challenge
Issues 1: The master and replica servers must have the same time zone setting

Today I was just going through P4 replication features with the correspondence of Disaster recovery(Replication), as well as bbalance load efficiently using p4 broker and p4 replica.

We can have cross-geo Disaster recovery(Replication) setup as soon as, we have same time zone setting in both (master and replica) server.  Replica server is unidirectional (read-only) so making same time zone in two difference location would not make any difference since all development activities will be happening though master servers/proxies only.

But
I learned that if we go replication with cross geo then we will not be able to take advantage of balance load efficiently as follows.

• We will not be able to take advantage of using replica server to reduce load and downtime on a primary server by Long-running queries, builds, and checkpoints in distributed geo environment.
• Perforce Broker to redirect commands to read-only replica servers to balance load efficiently across an arbitrary number of replica servers will not be having any advantage due to long distance and command will take more time to process in distributed geo environment.

Issues 2: p4 replicate and p4 pull (when replicating metadata) do not read compressed journals. Therefore, the master server must not compress rotated journals until the replica server has fetched all journal records from older journals

The replication process is designed to have as little latency as possible between the replica and the master; the compression/decompression of the journal
and manipulation of compressed data introduces additional delay and complexity which in turn increases the potential difference between the state of the master and the replica.

To Setup Replication
p4d -r $P4ROOT “-cset replica1#startup.1=p4 pull -i 2”

p4d -r $P4ROOT “-cset replica1#startup.1=p4 pull -u -i 2”

To unset Replication

p4d -r $P4ROOT "-cunset  replica1#startup.1"

To list all server configuration variables, 

use –cshow:

p4d -r $P4ROOT -cshow

This blog work still in progress…Still in Progress…

Reference

http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html
http://www.perforce.com/perforce/doc.current/manuals/cmdref/pull.html
http://www.perforce.com/perforce/doc.current/manuals/cmdref/configure.html#1040665
http://www.perforce.com/perforce/doc.current/manuals/cmdref/replicate.html#1046521
http://kb.perforce.com/article/1099
http://kb.perforce.com/article/1352/accessing-server-configuration-variables
http://kb.perforce.com/article/1099
http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html

The post Perforce Replication – What is Perforce Replication ? appeared first on scmGalaxy.

Command Line to find a Change list properties and associated path of the file in perforce server view:

Examples of the command you want:
p4 describe 1231928
p4 describe -s 1231928
p4 files @=1231928

Where 1231928 is the change list number.

The post Command Line to find a Change list properties in perforce server appeared first on scmGalaxy.

PerforceDFiles
Use:
This tool can be used to add thousands of files and directory in perforce server on single click which is having different-different hierarchy

Prerequisite:
Java should install and class path should set.

Step1:
Put the code under ClientSpec root folder in the same hierarchy which you want to add in perforce server.

Step2:
Create a changelist first. Just go to command prompt and type “p4 change”. Perforce will automatically create a changelist and will give you the changelist number. It will also ask you to update a text file with the changelist description. Just give the appropriate description there. Note the changelist number.

Step3:

The file file has one file called “config.properties”. So first update it with two values. The changelist number and the source path. The source path can be “D:/Perforce/Components/DatabaseServer”.
Use forward slash only “/”.

Step4: Once these files are updated, you can run the script file “makescript.bat” which will update the “checkinscripts.bat” with new checkin scripts.

Step5: Run “checkinscripts.bat” and refresh perforce console. See that new folder is created below components folder and the files are inside

Note: The file which will not be added into perforce server can be found in “missedfiles.log”

Links: http://www.scmgalaxy.com/index.php?option=com_docman&Itemid=110

The post Step by step guide on PerforceDFiles Tool | Perforce Tutorial appeared first on scmGalaxy.

Login perforce server using local client through batch script @echo off

p4 -p10.0.0.3:1666 –uUser_Name -P”User_Pass” -c”PERFORCE_CLIENT” client –o

Inputs:

-p à Server Address

-u à User Name

-P à Password

-c  à Client Name

-o à Write the client specification to standard output an editor.

10.0.0.3:1666 à ServerIP:Port

User_Name à User Name

User_Pass à User Password

PERFORCE_CLIENT à Perforce Local Client

The post How to Login Perforce Server by Using Batch File ? appeared first on scmGalaxy.