March 4, 2015

DVCS Zen, No Motorcycle Maintenance Required

Version Control

I’ve written previously about why we’ve decided to birth a new DVCS, so this post is instead about its use, the Zen of it all. And with apologies to Robert M. Pirsig[1], I use ‘Zen’ to refer to insight, and specifically insight into what’s happening when you start your first repo and work with it.

We are pleased to introduce our Helix Versioning Engine, built on the P4D you know and trust, but now with native DVCS capabilities that give you even more flexibility and power.

The Helix Versioning Engine makes it possible to work disconnected, start new projects and ideas in an instant, throw away what doesn’t work, toss content back and forth with a colleague until it’s ready for others, and eventually clean up your history and push to central server(s) to share with other teams. In other words, it gives developers all the freedom and power they know and love with DVCS systems.

You get started with our DVCS just like any other, by cloning an existing repository or initializing one from scratch. For sake of illustration, let’s create a new repo in a fresh directory:

$ p4 init
Server jwilliston-dvcs-142499891 saved.

That does exactly what long-time DVCS users expect: initializes a new repository in the current folder. One of the significant differences, however, is that a new personal server has just been created, with all the power of the Helix versioning engine under the hood. We’ll say more about that in future articles. For now let’s do a quick detailed list of the current folder:

-rw-rw-r-- 1 jwilliston jwilliston   55 Feb 18 14:51 .gitignore
-rw-rw-r-- 1 jwilliston jwilliston  212 Feb 18 14:51 .p4config
-rw-rw-r-- 1 jwilliston jwilliston   55 Feb 18 14:51 .p4ignore
drwx------ 4 jwilliston jwilliston 4096 Feb 18 14:51 .p4root

The .gitignore and .p4ignore files do what their names suggest: tell the command processor what kinds of files to ignore. By default they include everything already in the folder as well as anything named .svn, .git,  or *.swp. In contrast, the .p4config file contains configuration information used by the command processor, such as the user name, root folder location, etc.

The .p4root directory is special in that it contains the database and other files necessary for the Helix versioning engine. Server admins will recognize them, but far more importantly everyday users never have to care. The important thing is that all the repository data is stored locally, which provides maximal speed via the local file system.

These files are hidden by default, so all the typical user sees is an empty folder. After adding a sample file, we may run the p4 status command and get the following results: – reconcile to add //stream/main/

The simplest way to accept all changes is to issue the p4 reconcile command, which produces:

//stream/main/ – opened for add

The reconcile command adds files that aren’t already under version control, deletes files that aren’t there anymore, and marks for edit any files that have changed. Long time users may use the corresponding add, edit, and delete commands if preferred, but reconcile is more convenient.

Recording the changes is as easy as it always has been with the submit command. Just like this:

$ p4 submit -d “Added a hello-world script example.”
Submitting change 1.
Locking 1 files...
add //stream/main/
Change 1 submitted.

Notice what we didn’t do at any point: connect to a central, shared server. No, all of the above happened locally without any network connection at all. And that’s how we circle back to Zen.

We’ll talk about a variety of other great features in future installments. For now, check it out and send us your feedback. I’m thrilled with the quality of the implementation... and this is only the beginning.

[1] The author of the ever-popular Zen and the Art of Motorcycle Maintenance.

All Perforce Version Management & Collaboration Products Are Free for 20 Users, Now With DVCS Capabilities.