The basic Perforce architecture is client and server. There is a single server program (P4D) managing a repository and typically many client programs (such as P4V or P4) which communicate with that server as shown in the following diagram:
The server is responsible for maintaining the history of the contents of files, and for all of the information that describes the events that created that content (the metadata). Each client program is responsible for managing files and their contents within a particular workspace, and for communicating status changes to the server. In order to manage files a client program must connect to a server. Connecting to a server is covered in Chapter 2, The P4V GUI.
Users and client programs have no direct access to the repository managed by the server, so it is best to view the server as a black box. It is still useful to understand some of the services that the server provides.
The obvious services are to track the historic content of all the files managed by the server. The most visible part of this tracking is the actual content of all the versions of every file. An equally important part of this tracking is the metadata that the server maintains about file versions. Metadata describes details such as user, workspace, time, date, and check in comments, these are all part of the context in which the historic content was created.
Another service provided by the server is to track the state of files within each workspace, which it does in coordination with the client program. The state includes things such as whether files are present in the workspace, which version is present, whether the user has checked out particular files or versions, and so on.
The most important service provided by the server is to control and coordinate change, so having the server store information, rather than the client program, makes it available to everyone. This supports good engineering practice in the modern dynamic development environment. For example, when you check out a file the server tells you if the same file is checked out in other workspaces. A file checked out in multiple workspaces at the same time may or may not be a problem. Only a human can make that decision.
Client programs manage workspaces. At any one time, a client program manages a single workspace. It is a straightforward and fast operation for a client program to manage another workspace as necessary. It is common for users to have multiple workspaces on their local workstations such as their PC or laptop.
Note
Terminology warning – the word "client" has three meanings!
The word client is used in three different ways when talking about Perforce: to mean a client program, a client machine, or a client workspace. The first two meanings are fairly standard, but you will see the "client workspace" meaning in some of the Perforce documentation and in warning or error messages within P4V. The context usually makes it clear which meaning is intended. Unless otherwise specified, we use client to mean a client program.
Clients and their workspaces are isolated and independent. Clients must communicate with the server to determine what is going on in other workspaces (whichever machine those workspaces might be on). This is true even if there is more than one client running on a single machine. If you tell the server about changes that you intend to make within a workspace such as an edit, add, delete, or rename, this information can be communicated to other clients and thus to other users.
Clients can operate even if they are not connected with the server. This can be useful at customer sites, in airplanes, and at times when communication with the server is either not available or unstable. Because of their specific roles, the client and the server can always determine how to bring the client context up-to-date when they next communicate.