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
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
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 apartitioned
client against a forwarding replica -
Can't use p4 switch from a
partitioned
client -
p4 sync @partitioned-client-name
is equivalent tosync #none
-
The db.working and
db.have
check performed byp4d -xx
ignores thedb.have
tables for partitioned client workspaces. This results in the creation ofjnl.fix
records to delete the partitioned client'sdb.working
records for any open file revisions. Before replaying ajnl.fix
file, contact Technical Support.