May 22, 2014

My Own Private P4D

Version Control

Image: kahunapulej via Flickr

When working on personal projects, I want a versioning server that resides locally, offers an easy installation, quick initialization, and an effortless workflow for managing branching effortlessly.

Many would quickly point to Git, however, I do not want to sacrifice my knowhow of Perforce P4D and learn Git. Some would suggest P4Sandbox, but that requires a connection to a remote.

So I wrote a tool which gives most everything that P4Sandbox provides BUT without the remote server linkage (which is kind of important, but I’m ok without that for now). is the project page for this doodle.

Myp4 takes advantage of the p4config behavior and roots a p4d instance in whatever directory you want to use (just like the .git directory, except this one is called .myp4d).

It’s only one script (yes it’s bash based, yes it is MacOS x86_64 by default but you can change that part). On first use, it will download the latest 2014.1 p4 and p4d and use those for what it does under the covers.

Here’s an example of how easy it is to use this to start developing on some doodle of your own:

        mac-ateague:FFF$ p4 init

        mac-ateague:FFF$ echo rubber > flange

I think I have a better idea on what to do, I’ll go to another branch:

        mac-ateague:FFF$ p4 branch better
        There are pending changes, how do you want to proceed?
        (s) Shelve changes for later (r) Revert changes (q) Quit? s
        //branch/master/flange#1 - opened for add
        No files to branch
        Switch from master to better

Nice, it just shelved all of the work that I just did, cleaned up the workspace and switched me over to the newly created branch.

        mac-ateague:FFF$ echo silicon > flange

Time to submit all of my hard work. Let Perforce figure out what I did:

        mac-ateague:FFF$ p4 reconcile
        //branch/better/flange#1 - opened for add
        mac-ateague:FFF$ p4 submit -d 'All done!'
        Submitting change 2.
        Locking 1 files ...
        add //branch/better/flange#1
        Change 2 submitted.

Now let’s go back to the master branch: mac-ateague:FFF$ p4 switch master Switch from better to master Unshelving 1 //branch/master/flange#none - unshelved, opened for add Let’s merge 'better' into the ‘master’ branch:

        mac-ateague:FFF$ p4 mergefrom better
        There are pending changes, how do you want to proceed?
        (s) Shelve changes for later (r) Revert changes (q) Quit? r
        New files will be deleted, edits discarded, etc. Are you sure? y
        //branch/master/flange#none - was add, deleted
        //branch/master/flange#1 - branch/sync from //branch/better/flange#1
        No file(s) to resolve.
        Assuming no issues, you should now submit…

Right! I forgot that I had a previous idea for what to do. Yup, bounce the previous idea and go with the better one.

        mac-ateague:FFF$ cat flange 

That’s it. I created a Perforce installation, two branches, made changes, merged between them and wrapped it all up.

Here’s some eye-candy (courtesy of Zig!):


P.S. - If you follow the alternative install instructions (like I do), you can use this wrapper of ‘p4’ for everything. If it isn’t within a local Perforce installation, then it passes your command on to regular Perforce.

P.P.S. - Here are the Git commands to do the same thing: (10 using git, 9 using p4)

% git init
% echo rubber > flange
% git add flange
% git commit -m ‘Adding flange’     # This will create ‘master’ branch
% git checkout -b better
% echo silicon > flange                  # This is actually an edit not an add
% git commit -a -m ‘All done!’
% git checkout master
% git merge better
% cat flange                                  # flange containing rubber is part of the history