Read-only and partitioned clients in automated builds

Build automation scripts frequently create, sync, and delete clients. This can fragment the server's db.have table, which can cause your end-users to experience slower sync operations. To avoid this problem, consider adding one or more additional client workspaces of type readonly or partitioned for the exclusive use of automated builds.

Readonly and Partitioned Clients

Not journaled and not backed up by checkpoints

Client workspaces of type readonly and partitioned use their own db.have database table that is separate from the server's db.have table that contains the 'have-list' for all clients. To prevent fragmenting the server's db.have table, the db.have table of readonly and partitioned client workspaces are:

  • not journaled

  • not backed up by checkpoints

  • easily removed when the client workspace is deleted

These types of client workspaces are ideal for the build automation cycle that creates a client workspace, syncs it with the depot, performs builds, and finally deletes the client workspace.

readonly client workspaces

For build automation, where editing and submitting files is not required, consider readonly client workspaces. Typical commands run from a readonly client workspace:

partitioned client workspaces

Use partitioned client workspaces for the same purpose as readonly client workspaces, but with the additional ability to edit and submit files. Typical commands run from a partitioned client workspace, in addition to the the readonly commands above:

Creating a readonly or a partitioned client workspace

Before creating a readonly client workspace or a partitioned client workspace, configure the storage location for the db.have tables of these types of client workspaces by setting the client.readonly.dir server configurable. For example:

p4 configure set client.readonly.dir=part-db-have

Note

Although the name of this configurable contains "readonly", its setting also applies to partitioned client workspaces.

Relative paths specified in client.readonly.dir are relative to P4ROOT, but absolute paths can also be specified. The client.readonly.dir server configurable does not require a server restart. The Helix Server creates the directory upon first usage if it doesn't already exist.

To create a client workspace that is readonly or partitioned, set the Type: field in the client specification to either readonly or partitioned.

For example,

p4 client my-readonly-client
...
Type: readonly

or

p4 client my-partitioned-client
...
Type: partitioned
Tip

Although a readonly client cannot be converted to a writeable client, a readonly client can be converted to a partitioned client by updating the Type: field in the client specification. See p4 client > Options > -T type in Helix Core Command-Line (P4) Reference.

Limitations

Readonly and partitioned client workspaces have the following limitations:

  • Are not journaled

  • Are not checkpointed

  • Can't use p4 changes -m1 @partitioned-client-name

  • Can't use p4 fstat #have from a partitioned client against a forwarding replica

  • Can't use p4 switch from a partitioned client

  • p4 sync @partitioned-client-name is equivalent to sync #none

  • The db.working and db.have check performed by p4d -xx ignores the db.have tables for partitioned client workspaces. This results in the creation of jnl.fix records to delete the partitioned client's db.working records for any open file revisions. Before replaying a jnl.fix file, contact Technical Support.