November 24, 2015

Read-Only Clients in Helix Server 2015.2

Traceability

This one is for you, DevOps engineers:

One of the Helix Versioning Engine’s (P4D) strengths is that it knows exactly what version of every file you have synced to your desktop. This granularity at the file level means that calculating the latest revision of a file a user might need is very fast. 

The information for all client workspaces is stored in a single “havelist” database table. This table is usually the largest amount of meta-data tracked in your repository (although in the 2015.1 P4D release we reduced its size by about 30%).

The number of client workspaces used for build tasks can outweigh the number of developers’ clients 10:1 on some sites. Build clients are also often short-lived, created for a few builds until the release is finished and then torn down again. This process can fragment the “havelist” database table over time, consuming time and space. Helix Server administrators therefore tend to rebuild the database tables from time to time to defragment them.

To make this process more efficient DevOps engineers use different techniques, from ‘p4 sync –p’ (only send the files, do not update the server’s database) to dedicated build replicas with their own database tables.

Now there is a new weapon in your arsenal of lightweight build processes: read-only clients. 

In the majority of cases any files synced to a build client workspace do not get updated—and certainly no changes are submitted back to the Helix Server. The new read-only clients make use of this fact: they have their own separate database table that can easily get cleaned up without affecting the main “havelist” table.

To make use of this feature, your administrator only needs to define the location of the separate database tables once, using a configurable (otherwise you will get the error “Storage location 'client.readonly.dir' needs to be set by the administrator.”):

p4 configure set client.readonly.dir=clients.readonly

Now you can create a read-only client by setting the new Type field to readonly. Note that you can use this client in the normal way to sync files, but you cannot add, edit, delete, or integrate into any of these files.

These private tables do not get journalled and therefore do not appear in the checkpoint—they are meant to be short-lived. Once you delete the client, its private database table gets cleaned up again without any impact on your “havelist” table, removing the need to defragment your database tables. 

And there you have it: a neat, simple solution that will make the lives of DevOps engineers and administrators alike much easier in the future.

Why don’t you try out the 2015.2 version of Perforce Helix? You can find out what else is new in 2015.2 from the release notes and previous blog articles.

As usual, contact me @p4sven if you have any questions or feedback. Happy hacking!