p4 client
Synopsis
Create or edit a client workspace specification and its view.
The command p4 workspace
is an alias for p4
client
.
Syntax
p4 [g-opts
] client [-f] [-t
template
] [-T type
]
[clientname
]
p4 [g-opts
] client -o [-t
template
] [-T type
]
[clientname
]
p4 [g-opts
] client -d [-f
[-Fs]]clientname
p4 [g-opts
] client -s [-S
stream
| -t
clientname
]
clientname
p4 [g-opts
] client -S
stream
[[-c change
]
-o] [clientname
]
p4 [g-opts
] client -i
[-f]
p4 [g-opts
] client -d -f
--serverid=serverid
[-Fs]
Description
A Perforce client workspace is a set of files on a user’s machine that
mirror a subset of the files in the depot. More precisely, it is a named
mapping of depot files to workspace files. Use the p4 client
command to create or edit a client workspace specification; invoking
this command displays a form in which the user enters the information
required by Perforce to maintain the workspace.
The p4 client
command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
P4EDITOR
. For new workspaces, the client name defaults to the
P4CLIENT
environment variable if set, or to the current host name.
Saving the file creates or modifies the client spec.
Although there is always a one-to-one mapping between a client workspace
file and a depot file, these files do not need to be stored at the same
relative locations, nor must they have the same names. The
client view, which is specified in the p4 client
form’s View:
field, specifies how files in the workspace are mapped to
the depot, and vice-versa.
When p4 client
completes, the new or altered workspace
specification is stored in the Perforce database; the files in the
workspace are not touched. The new view does not take effect until the
next p4 sync
.
To submit changes to a stream, you must associate the stream with a
workspace, using the command p4 client -S stream clientname
.
To change the stream associated with a workspace, use the command p4
client -s -S stream clientname
.
Form Fields
Field Name | Type | Description |
---|---|---|
|
Read-only |
The client workspace name, as specified in the When called without a clientname argument, |
|
Writable, mandatory |
The name of the user who owns the workspace. The default is the user who created the workspace. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. |
|
Read-only |
The date the workspace specification was last modified. |
|
Read-only |
The date and time that the workspace was last used in any way. The access time is only valid for the server where the client resides — where it was created or where it was moved to. This is an issue only in a commit-edge architecture. Reloading a workspace with |
|
Writable, optional |
The name of the workstation on which this workspace resides. If included, operations on this client workspace can be run only from this host. If not set, access is allowed from any host. The hostname must be provided exactly as it appears in the output of
This field is meant to prevent accidental misuse of client workspaces on
the wrong machine. Providing a host name does not guarantee security,
because the actual value of the host name can be overridden with the
|
|
Writable, optional |
A textual description of the workspace. The default text is |
|
Writable, mandatory |
The directory (on the local host) relative to which all the files in
the If you change this setting, you must physically relocate any files that
currently reside there. On Windows client machines, you can specify the
root as |
|
Writable, optional |
Up to two optional alternate client workspace roots. Perforce applications use the first of the main and alternate roots that
match the application’s current working directory. Use the
This enables users to use the same Perforce client workspace specification on multiple platforms, even those with different directory naming conventions. If you are using multiple or alternate workspace roots (the If you are using a Windows directory in any of your workspace roots, you
must specify the Windows directory as your main workspace root and
specify your other workspace roots in the For example, an engineer building products on multiple platforms might
specify a main client root of |
|
Writable, mandatory |
A set of seven switches that control particular workspace options. See Usage Notes for a listing of these options. |
|
Writable, mandatory |
Options to govern the default behavior of
|
|
Writable, mandatory |
Configure carriage-return/linefeed (CR/LF) conversion. See Usage Notes for a listing of these options. |
|
Writable, optional |
Associates the workspace with the specified stream. Perforce generates the view for stream-associated workspaces: you cannot modify it manually. |
|
Writable, optional |
A changelist number that sets a back-in-time view of a stream. When This field is ignored unless the |
|
Writable, optional |
If set, restricts usage of the workspace to the named server. If unset, use is allowed on master server and on any replicas of the master other than Edge servers. |
|
Writable, multi-line |
Specifies the mappings between files in the depot and files in the
workspace. See |
|
Writable, optional, multi-line |
Restricts access to depot paths to a particular point in time. Files specified for the ChangeView field are read-only: they may be opened but not submitted. For example: //depot/path/...@1000 Revisions of the files in the specified path will not be visible if they were submitted after the specified changelist number. Files matching a ChangeView path may not be submitted. |
|
Writable, optional |
By default clients are Using writeable clients in build automation scripts can lead to
|
|
Writable, optional |
Not currently in use. Applies only to clients bound to cluster workspace servers. If a backup startup process is launched on a cluster workspace-server,
by default all writable clients (see Note: If the backup startup process is configured with auto-unload unused clients on, neither readonly clients nor those with backup disabled, will be considered for auto unload. For complete information, see version 15.1 of Helix Versioning Engine Administrator Guide: Cluster Management. |
Options
|
Delete the specified client workspace whether or not the workspace is
owned by the user. The workspace must be unlocked and must have no
opened files or pending changes. (The If you try to forcibly delete a client bound to another server, you need
to specify the |
|
Allows the last modification date, which is normally read-only, to be
set. Administrators can use the Use of this option requires |
|
Allows the deletion of a client even when that client contains shelved
changes. The client is deleted and the shelved changes are left
intact. (You must use the |
|
Read the client workspace specification from standard input. |
|
Write the client workspace specification to standard output. |
|
When used with |
|
Switch workspace view. To switch the workspace view to a stream,
specify Switching views is not allowed in a client that has opened files. The
|
|
If you try to forcibly delete a client bound to another server, you
need to specify the This variant of the |
|
Associates the workspace with the specified stream, which is used to generate its workspace view. |
|
Copy client workspace clientname's view and options into the |
|
By default clients are |
|
See “Global Options”. |
Usage Notes
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
N/A |
N/A |
|
- Use quotation marks to enclose depot-side or client side mappings of file or directory names that contain spaces.
- Spaces in workspace names are translated to underscores. For example,
typing the command
p4 client "my workspace"
creates a workspace calledmy_workspace
. - By default, any user can edit any workspace specification with
p4 client
clientname
. To prevent this from happening, set thelocked
option and usep4 passwd
to create a password for the workspace owner. -
To specify a workspace on Windows that spans multiple drives, use a
Root:
ofnull
, and specify the drive letters in the workspace view. For instance, the following workspace spec with anull
root maps//depot/main/...
to an area of theC:
drive, and other releases to theD:
drive:Client: eds_win Owner: edk Description: Ed's Windows Workspace Root: null Options: nomodtime noclobber SubmitOptions: submitunchanged View: //depot/main/... "//eds_win/c:/Current Release/..." //depot/rel1.0/... //eds_win/d:/old/rel1.0/... //depot/rel2.0/... //eds_win/d:/old/rel2.0/...
Use lowercase drive letters when specifying workspaces across multiple drives.
Options field
The Options:
field contains six values, separated by spaces. Each of
the six options have two possible settings; the following table provides
the option values and their meanings:
Option | Choice | Default |
---|---|---|
|
If set, unopened files in the workspace are left writable. If A setting of |
|
|
If set, a If |
|
|
If set, the data stream between the user’s workstation and the Perforce service is compressed. The compress option speeds up communications over slow links by reducing the amount of data that has to be transmitted. Over fast links, the compression process itself may consume more time than is saved in transmission. In general, compress should be set for line speeds under T1, and should be left unset otherwise. |
|
|
Grant or deny other users permission to edit or delete the workspace
specification. (To make a If |
|
|
For files without the
For files with the Files with the |
Ignored for files with the |
|
If set, By default, if a directory in the client workspace is empty, (for
instance, because all files in the depot mapped to that directory have
been deleted since the last sync), a If the |
|
Processing line endings
The LineEnd:
field controls the line-ending character(s) used for text
files in the client workspace. Changing the line end option does not
actually update the client files; you can refresh them with p4 sync
-f
.
The LineEnd:
field accepts one of five values:
Option | Meaning |
---|---|
|
Use mode native to the client (default) |
|
UNIX-style (and Mac OS X) line endings: |
|
Mac pre-OS X: |
|
Windows- style: |
|
The When you sync your workspace, line endings are set to The most common use of the The |
For more information about how Perforce uses the line-ending settings, see "CR/LF Issues and Text Line-endings" in the Perforce knowledge base:
Working with Streams
Without -s
, the -S stream
option can be used to create a new
client spec dedicated to a stream. If the client spec already exists,
and -S
is used without -s
, it is ignored. Using -S
sets the
client’s Stream
field. The special syntax
-S //
can be used to set both a
/stream
@changelist
Stream
and StreamAtChange
at the same time.
The -S stream
option can be used with -o -c change
to inspect an
old stream client view. It yields the client spec that would have been
created for the stream at the moment the change was recorded.
Working with build servers
A server of type build-server (see p4 help server
) is a replica
that supports build farm integration, and the p4 client
command
may be used to create or edit client workspaces on a build-server. Such
workspaces may issue the p4 sync
command in addition
to any read-only command supported by the replica. For more information,
run p4 help buildserver
.
When creating or editing a client workspace for a build-server, the
client specified by the optional name
argument, as well as the client
specified by the P4CLIENT
environment variable or via the global -c
client
argument must not exist, or must be restricted to this server;
this command may not be used to create or edit a workspace that is not
restricted to this build-server.
Using read-only clients
Build automation scripts, which routinely create, sync, and tear down
clients, may fragment the db.have
table over time. To avoid this, you
can specify the type readonly
for these clients. Such clients cannot
add, delete, edit, integrate, or submit files, but this should not be an
issue in build scripts.
A readonly client is assigned its own personal db.have
database table,
and the location of this table is specified using the
client.readonly.dir
configurable.
To set up a read-only client:
-
Set the
client.readonly.dir
configurable to the directory where the db.* tables for the client should be stored.For example, if you create a read-only client whose name is
myroc
and you setclient.readonly.dir
to/perforce/1
, then syncing files using this client will write to the following database/perforce/1/server.dbs/client/
hashdir
/db.myroc - Set the
Type
field of the client spec toreadonly
.
Examples
|
Edit or create the workspace specification named by the value of
|
|
Create or edit a workspace named |
|
Delete the workspace named |