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.
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
# Perforce export P4CONFIG=.p4config export P4IGNORE=.p4ignore export P4EDITOR=vim
You might have noticed the
P4IGNORE variable in my
P4IGNORE files work just like
One of my
P4PORT=workshop.perforce.com:1666 P4USER=zachwhaley P4CLIENT=project
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.
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
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 Description: Created by zachwhaley. Root: /project Options: allwrite noclobber nocompress unlocked nomodtime normdir SubmitOptions: submitunchanged LineEnd: local View: //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
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.
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 ==== 33a34,42 > // 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 Description: <enter description here> Files: //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 perf.py # 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.