08 Apr 2014

Until now, I’ve only really used distributed version control software; Mercurial in college and Git since I got a Github account. I started working at Cisco and started using Perforce. It’s been a little weird, but I think I’m getting the hang of it.

My Environment

I set Perforce’s P4CONFIG variable in my .bashrc to let me put a config file at the root of each of my Perforce repositories. This let’s me easily change my server, username, client, etc. for each repository. At work I like to have a client for each branch we work on; this lets me do just that.

My Perforce settings in my .bashrc

# Perforce
export P4CONFIG=.p4config
export P4IGNORE=.p4ignore
export P4EDITOR=vim

You might have noticed the P4IGNORE variable in my .bashrc.

P4IGNORE files work just like .gitignore.

One of my .p4config files

Bash Completion

The bash completion in Git is really convenient, but unfortunately Perforce’s CLI program doesn’t come with a bash completion script. So I made my own.

Distributing Perforce

Perforce is not a distributed version control system (unless you’ve upgraded to Perforce Helix, in which case you should be using the Git integration), but there are ways to make it seem like it is.

Write All the Files!

So the Perforce settings at my work force all local files to be readonly by default. I feel like this hinders my programming flow and is just unnecessary. So I changed it.

The option to make all files writeable is in your Perforce client, which can be viewed with the following command.

$ p4 client

This will open your client settings in an editor to be viewed and changed. If you don’t like the default editor you can change this by setting the Perforce variable P4EDITOR in your bash environment, like below. This can also be set in your .bashrc like I did above.

$ export P4EDITOR=vim # For Unix users
$ p4 set P4EDITOR=vim # For (Mac)OSX users
$ p4 client

In the client settings, change the Option noallwrite to allwrite, and save the file.

# A Perforce Client Specification.
# ...
# A bunch of stuff is here

Client:	project

Update:	2014/04/07 15:32:56

Access:	2014/04/07 19:57:03

Owner:	zachwhaley

Host:	zachs-computer

	Created by zachwhaley.

Root:	/project

Options:	allwrite noclobber nocompress unlocked nomodtime normdir

SubmitOptions:	submitunchanged

LineEnd:	local

	//depot/zachwhaley/project/... //project/...

This will save the client settings, but your files won’t become writeable just yet.

Perform a complete sync to update all your repository’s file’s permissions.

# Make sure any uncomitted changes to the repo are saved off somehow,
# before executing the next step.
$ cd /to/root/of/repo/
$ p4 sync -f ... # The ... means do this recursively starting here

You can now change any file you want! But what happens when It’s time to commit a change?

Reconcile with Lord Server

After I’ve made my changes to the code (for better or worse), I’ll run p4 status.

Just like Git, this command tells you what has been modified, added, or deleted from the server’s code base.

$ p4 status
bar.cpp - reconcile to add //depot/zachwhaley/project/bar.cpp#1
bar.hpp - reconcile to add //depot/zachwhaley/project/bar.hpp#1
foo.cpp - reconcile to edit //depot/zachwhaley/project/foo.cpp#2

Unlike Git, Perforce has no idea how the files changed, only that these files are different from the server’s files.

I still have to tell Lord Server which files I want to change and how. Since I’m happy with the files listed, it is time to reconcile with Lord Server and tell them what I have done.

$ p4 reconcile
//depot/zachwhaley/project/bar.cpp#1 - opened for add
//depot/zachwhaley/project/bar.hpp#1 - opened for add
//depot/zachwhaley/project/foo.cpp#2 - opened for edit

Perforce has now opened (checked out) the files for me.

Use p4 opened To see a list of your open files. And p4 diff to see code changes for open files

$ p4 opened
//depot/zachwhaley/project/bar.cpp#1 - add default change (text)
//depot/zachwhaley/project/bar.hpp#1 - add default change (text)
//depot/zachwhaley/project/foo.cpp#2 - edit default change (text)
$ p4 diff foo.cpp
==== //depot/zachwhaley/project/foo.cpp#2 - /project/foo.cpp ====
> // p4 ain't that bad

Change, Submit, and Go Home

When I’m finally ready to commit my code, I create a change.

I use Perforce changes like Git staging. They are similar in that they identify what is going to change, without actually making the change happen. They are not similar in that I have to create a change description (commit message) when creating the change. Don’t worry though, this description can be changed before submission

p4 change will open an editor where I add my description and specify which files go with this change.

$ p4 change
# A Perforce Change Specification.
# ...
# A bunch of stuff is here

Change:	new

Client:	project

User:	zachwhaley

Status:	new

	<enter description here>

    //depot/zachwhaley/project/bar.cpp # add
    //depot/zachwhaley/project/bar.hpp # add
    //depot/zachwhaley/project/foo.cpp # edit

A change number will be printed after I save my new change.

$ p4 change
Change 1010 created with 3 open file(s).

This number uniquely identifies this change and can be used to edit the change description, add or remove files to the change, etc.

$ p4 change 1010 # Edit change 1010
$ p4 revert -c 1010 somedir/* # Reverts files in somedir that belong to change 1010
$ p4 edit -c 1010 # Adds a file to be edited in change 1010
$ p4 update # Merges your code with changes from others

Now to submit my change

$ p4 submit -c 1010

Code has been checked into the Mother Repo, and I am done.


A big thanks to G Weiss and Matt Attaway.