Thanks for the Invitation to the PerForce Group

Thanks for the Invitation to the PerForce Group.

Thanks for the Invitation to the PerForce Group.

 

However, I have no idea what to discuss here as I have never used PerForce and doubt very much I ever will.  After 10 years of experience with ClearCase and ClearQuest, I have been unemployed for 18 months now, and my COBRA ends this Friday, May 6th.  I got very tired of applying for jobs where I have been run over by the technology revolution.  I am also tired of recruiters who contact me and do not do their homework.  They are wasting their time, mine. and that of the hiring manager.  For that reason I needed to look outside the box and am now undergoing PMP training.  Later I will be taking the PMP Certification Exan.

  • Rajesh Kumar

    Rajesh Kumar 

    Thats good news indeed that you are going through PMP certification.

    However, I guess this discussion can be made on group Discussion place instead of blog place.

    What you say?

  • mfeighner

    mfeighner 

    Yes, that would be in order.  I posted here only because that is where I was invited.

  • Rajesh Kumar

    Rajesh Kumar 

    Hi mfeighner,

    its been long time to see you post here. Hows life going on? Where you have joined recently?

Tagged : / / / / /

How to Setup p4 in Linux / Unix

How to Setup p4 in Linux / Unix
Well many people have these questions to me that they are facing issues setting up p4 client in Linux or Unix. The Solution is pretty much straight forwards but sometimes we miss some of things which delay the setup process.
Here I have tried to points out these already available on Perforce Knowledge base site.
Download and Installations:

1. Download the p4 executable file from the Perforce web site:

http://www.perforce.com/perforce/downloads/index.html 
The Perforce client programs are typically downloaded to /usr/local/bin.

2. Make the p4 file executable (chmod +x p4)

Perforce Configuration and Workspace Setting
Method 1
Using Config Files:
Config files are text files containing Perforce settings that are in effect for files in and below the directory where the config file resides. Config files are useful if you have multiple client workspaces on the same machine. By specifying the settings in config files, you avoid the inconvenience of changing system settings every time you want to work with a different work-space.
To use config files, you define the P4CONFIG environment variable, specifying a file name (for example, .p4config). When you issue a command, Perforce searches the current working directory and its parent directories for the specified file and uses the settings it contains (unless the settings are overridden by command-line flags).
P4CONFIG = .p4config
Each setting in the file must be specified on its own line, using the following format:
setting=value

The following settings can be specified in a config file.

Setting Description
P4CLIENT Name of the current client workspace.
P4EDITOR The editor invoked by those Perforce commands that use forms.
P4HOST Hostname of the client workstation. Only useful if the Host: field of the current client workspace has been set in the p4 client form.
P4PASSWD Supplies the current Perforce user’s password for any Perforce client command.
P4PORT The host and port number of the Perforce server or proxy with which to communicate.
P4USER Current Perforce user name.

For details about these settings, refer to the Perforce Command Reference.

Example: Using config files to handle switching between two workspaces
Ona switches between two workspaces on the same machine. The first workspace is ona-ash. It has a client root of /tmp/user/ona and connects to the Perforce server at ida:1818. The second workspace is called ona-agave. Its client root is /home/ona/p4-ona, and it uses the Perforce server at warhol:1666.

Rama sets the P4CONFIG environment variable to .p4config. She creates a file called .p4config in /tmp/user/rama containing the following text:
P4PORT=ida:1818
P4CLIENT=ona-ash

She creates a second .p4config file in/home/rama/p4-ona. It contains the following text:
P4PORT=warhol:1666
P4CLIENT=ona-agave

Any work she does on files under /tmp/user/rama is managed by the Perforce server at ida:1818 and work she does on files under /home/rama/p4-ona is managed by the Perforce server at warhol:1666.

Method 2: Environment Variable Setting

To configure server connection settings using environment variables, set P4PORT to host:port, as in the following examples.

If the server is running on and is listening to port set P4PORT to
your computer 1666 localhost:1666
perforce 1666 1666

Example:
export P4PORT=X.X.X.X\:1667
export P4PASSWD=pass
export P4USER=user
export P4CLIENT=Sonar
export PATH

Defining client workspaces 
To define a client workspace:

1. Specify the workspace name by setting P4CLIENT; for example, on a UNIX system:

$ P4CLIENT=bruno_ws ; export P4CLIENT

 

2.

Issue the p4 client command.

Perforce displays the client specification form in your text editor.

3. Specify (at least the minimum) settings and save the specification.

The minimum settings you must specify to configure a client workspace are:

 

Workspace name

The workspace name defaults to the client machine’s hostname, but a client machine can contain multiple workspaces. To specify the effective workspace, set P4CLIENT.

Client root

The client root is the top directory of your client workspace, where Perforce stores your working copies of depot files. Be sure to set the client root, or you might inadvertently sync files to your client machine’s root directory.

Note:
To specify server settings on the command line, use the -p flag. For example:
p4 -p localhost:1776 sync //depot/dev/main/jam/Jambase

Reference:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/02_config.html#1069873 
http://www.perforce.com/perforce/doc.current/manuals/p4guide/02_config.html#1071378 
http://www.perforce.com/perforce/doc.current/manuals/p4guide/01_install.html#1070774

Tagged : / / /

Perforce Customization To Revert Changelist

Perforce Customization To Revert Changelist

Attachech Python File: Download here Perforce Python script to revert Changelist

Purpose

In Perforce if we check in any change list and in case if we want to revert the change list. Perforce does not have feature to Revert Change List.

We have to do it manually by using following steps.

1) Take a change list version which is predecessor of the current one which we want to revert
2) Do head sync to that change list revision.
3) Check out the files which we want to revert. Resolve them and check in

But we can very well eliminate the above three manual steps and automate the process of Reverting Change list by Customizing Perforce to have Revert Change List Feature.
This feature will be very useful if the Changelist which we want to revert have large number of files

Risk
There is no Risk with this feature because the changelist which we revert are not directly submitted. When we do a Revert Change List a new Change List will be created and we have the capability to resolve the conflict if there are more than one Revision for that file.

Required Software Version
Download Recent version of Python from http://www.python.org/download/ and   Install Python and set the path for library files of python in the environment variables just like java.

Software Program Required for Customization

I have downloaded Python Program from the following URL which will help in Reverting Change List. (http://www.tilander.org/aurora/2007/06/reverting-a-perforce-changelis.html).

Perforce Client Side Changes for Customization

Following Customization needs to be done to add Revert ChangeList option in  perforce.

1.    Open Perforce
2.    Go to Tools >> Customize
3.    Click Add Button
4.    Enter Name as RevertChangeList, Give the location of the Python Program
5.    Give the argument as -c $c -p $p -u $u %c
C – Client
P –  Port Number
U –User

image

Note : Make sure “Close window upon exit” is not checked initially for the first time. So that we can see the success message in console.
In case if it is checked. If the Python Program fails. Then we may not be able to see the message.

6.    Once this is done then Click View Submitted Change List. Right click the change list which you want to revert and click RevertChangeList.

 

image

7.    Once this is done all the files that were reverted will be available under Default Changelist.
8.    Create New Changelist and move all from Default Changelist.
9.    Check the whether they are reverted properly. If there are some version conflict then resolve them and checkin.
10.    Using this feature I had reverted changelist Number : 163806
11.    Outside Perforce also this utility can be run. We can also run the utility from windows prompt by giving following command

Command :
p4revert.py -c <Client> -p <Port> -u <User> <ChangeList>

Example:
p4revert.py -c Mramchandran -p 10.10.50.201:1666 -u jayesh 163806

This is not tested. It is also convenient to use through perforce.

Troubleshooting

1.If my Revert ChangeList contains file say A.java and that file is also part of another change list in the client machine. Then the file A.java will not be reverted.
2. Always check the number of files that are present in the changelist is same as same number of files that are present in the new change list once RevertChangeList is done.

Limitations
1. The only limitation this tool has is the Revert ChangeList customization is written in Python. It will be good if we can understand the logic and convert to Java.

References

1. http://www.tilander.org/aurora/2007/06/reverting-a-perforce-changelis.html
2. http://kb.perforce.com/?article=014
3. http://www.python.org/download/

Contributed Made by: Ramchandran M

Tagged : / / / /

Ways to Pass Password in Triggers file or Script file in Perforce

Option 1
If your Perforce server is set to security level 2 or lower you can have your trigger script run as the same user every time (typically a “background” user). Then, either have the server’s P4PASSWD environment variable set to the background user’s password,

Option 2
You can also use the -P flag to specify the password with the P4 commands issued by the script.

Option 3
You can echo the password and pipe it to the login command. Note that there is no space between the password and the pipe symbol.

echo <password>| p4 login

Option 4
If you do not want to place a password in the script, you can use a text file containing the password. Make sure this password file has appropriate read and write privileges.

p4 login < password.txt

Option 5
A more secure method is to use ticket based authentication and a group to keep a background user “logged in” at the Perforce server:

1. Create a group:

p4 group always_on

2. Add your background user to the “Users” field.

3. Change the timeout from the default setting (12 hours), which is set in seconds. The new value depends on the server version:

# 2008.1 and later: Set this value to “unlimited”. A timeout value of zero is no longer accepted.

# 2005.1 to 2007.3: Set this value to zero.

# 2004.2 and earlier: Set this to a very large value — but not too large, as some server versions do not handle situations where the timeout is set to exceed the “Unix Epoch”, which is approximately in the year 2038. A safe value is 315532800 seconds, which is about 10 years.

# Save the group.

# In your trigger script, log the background user in and run the trigger once.

echo password| p4 -p server:port -u username login

# If the trigger runs properly, you can remove the password line.

The user now remains logged in. Since this is ticket based authentication, they remain logged in even if the server is shut down or the hardware is rebooted.

Tagged : / / /

Perforce Command Line Global Options

<!– .style1 { font-size: 24px; font-weight: bold; } –>

Perforce Command Line Global Options

Global options for Perforce commands; these options can be supplied on the command line before any Perforce command.

Syntax
p4 [-cclient -ddir -Hhost -pport -Ppass -uuser -xfile -Ccharset -Qcharset -Llanguage] [-G] [-s] [-z tag] cmd [args …]
p4 -V
p4 -h

 

Options
 
-c client
Overrides any P4CLIENT setting with the specified client name.
-d dir
Overrides any PWD setting (i.e. current working directory) and replaces it with the specified directory.
-G
Causes all output (and batch input for form commands with -i) to be formatted as marshalled Python dictionary objects. This is most often used when scripting.
-H host
Overrides any P4HOST setting and replaces it with the specified hostname.
-p port
Overrides any P4PORT setting with the specified port number.
-P pass
Overrides any P4PASSWD setting with the specified password.
-s
Prepends a descriptive field (for example, text:, info:, error:, exit:) to each line of output produced by a Perforce command. This is most often used when scripting.
-u user
Overrides any P4USER, USER, or USERNAME setting with the specified user name.
-x file
Instructs Perforce to read arguments, one per line, from the specified file. If file is a single hyphen (-), then standard input is read.
-C charset
Overrides any P4CHARSET setting with the specified character set.
-Q charset
Overrides any P4COMMANDCHARSET setting with the specified character set.
-L language
This feature is reserved for system integrators.
-z tag
Causes output of many reporting commands to be in the same tagged format as that generated by p4 fstat.
-V
Displays the version of the p4 client program and exits.
-h
Displays basic usage information and exits.

 

Usage Notes
Be aware that the global options must be specified on the command line before the Perforce command. Options specified after the Perforce command will not be interpreted as global options, but as options for the command being invoked. It is therefore possible to have the same command line option appearing twice in the same command, being interpreted differently each time.
For example, the command p4 -c anotherclient edit -c 140 file.c will open file file.c for edit in pending changelist 140 under client workspace anotherclient.
The -x option is useful for automating tedious tasks; a user adding several files at once could create a text file with the names of these files and invoke p4 -x textfile add to add them all at once.
The -x option can be extremely powerful – as powerful as whatever generates its input. For example, a UNIX developer wishing to edit any file referring to an included file.h file, for instance, could grep -l file.h *.c | cut -f1 -d: | p4 -x – edit.
In this example, the grep command lists occurrences of file.h in the *.c files, the -l option tells grep to list each file only once, and the cut command splits off the filename from grep’s output before passing it to the p4 -x command.
The -s option can be useful in automated scripts.
For example, a script could be written as part of an in-house build process which executes p4 -s commands, discards any output lines beginning with “info:”, and alerts the user if any output lines begin with “error:”.
Python developers will find the -G option extremely useful for scripting. For instance, to get a dictionary of all fields of a job whose ID is known, use the following:
job_dict = marshal.load(os.popen(‘p4 -G job -o ‘ + job_id, ‘rb’))
In some cases, it may not be intuitively obvious what keys are used by the client program. If you pipe the output of any p4 -G invocation to the following script, you will see every record printed out in key/value pairs:
Tagged : / / / / /

Perforce Command Line

Command

Description

p4 add
Open file(s) in a client workspace for addition to the depot.
p4 admin
Perform administrative operations on the server.
p4 branch
Create or edit a branch specification and its view.
p4 change
Create or edit a changelist specification.
p4 changelists
List submitted and pending changelists.
p4 changelist
Create or edit a changelist specification.
p4 client
Create or edit a client workspace specification and its view.
p4 clients
List all client workspaces currently known to the system.
p4 delete
Open file(s) in a client workspace for deletion from the depot.
p4 depot
Create or edit a depot specification.
p4 depots
Display a list of depots known to the Perforce server.
p4 describe
Provides information about changelists and the changelists’ files.
p4 groups
List groups of users.
p4 group
Add or delete users from a group, or set the maxresults, maxscanrows, and timeout limits for the members of a group.
p4 have
List files and revisions that have been synced to the client workspace
p4 info
Display information about the current client and server.
p4 integrate
Open files for branching or merging.
p4 integrated
Show integrations that have been submitted.
p4 job
Create or edit a defect, enhancement request, or other job specification.
p4 jobs
List jobs known to the Perforce server.
p4 label
Create or edit a label specification and its view.
p4 labels
Display list of defined labels.
p4 lock
Lock an opened file against changelist submission.
p4 login
Log in to a Perforce server by obtaining a ticket.
p4 logout
Log out of a Perforce server by removing or invalidating a ticket.
p4 passwd
Change a user’s Perforce password on the server.
p4 rename
Renaming files under Perforce.
p4 resolve
Resolve conflicts between file revisions.
p4 revert
Discard changes made to open files.
p4 set
Set Perforce variables in the Windows registry.
p4 submit
Send changes made to open files to the depot.
p4 sync
Copy files from the depot into the workspace.
p4 tag
Tag files with a label.
p4 triggers
Edit a list of scripts to be run conditionally whenever changelists are submitted, forms are updated, or when integrating Perforce with external authentication mechanisms.
p4 user
Create or edit Perforce user specifications and preferences.
p4 users
Print a list of all known users of the current server.
p4 verify
Verify that the server archives are intact.
p4 workspace
Create or edit a client workspace specification and its view.
Tagged : / / / / /

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…

Auto 
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

where:
–> 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
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
Tagged : / / /