Depot is a word that you will frequently see within this book, Perforce documentation, and in the P4V interface. In general, it refers to a directory structure that the server uses to store the historic content of files.

The repository that the server manages consists of one or more depots. Each depot has a unique name. A depot acts like a hierarchical file system containing folders and files. It is very common for a repository to have multiple depots. Creating depots is an administrator function.

Workspace is a common word within the source control community. Unfortunately, there seem to be more definitions for workspace than there are tools that support them. For Perforce, the term workspace refers to a collection of files, usually on a user's local machine, that the user wants Perforce to manage. Implicit to the Perforce concept of workspace is the relationship between repository files and the files in that workspace.

Workspaces usually contain a copy of a small subset of all the files in the repository, for example, only the files relevant to a particular project. Users operate on the copies of the files in their workspace, and submit their changes back to the repository. If another user has their workspace configured to see the same project, they can update their workspace to receive the latest copies of any updated files whenever they are ready to do so. In the following diagram, two developers (Fred and Wilma) exchange changes between their workspaces via the repository:

There are many aspects of workspaces that a user may want to manage. However, for basic operations a single workspace on your workstation may be all that you need. Managing workspaces is covered in Chapter 6, Managing Workspaces.

Changelist is a core Perforce concept. It is the fundamental unit of change to the repository, you don't check in files one-by-one, you check in changelists one-by-one. Each changelist contains one or many files. Changelists with thousands, tens of thousands, and even more files are not uncommon. In each workspace, it is possible to have multiple active changelists that are not yet checked in.

Changelist refer to a specific set of content and metadata changes made to the files managed by the server. Changelists have a unique numerical identifier and other attributes such as status, description, date and time of submission, and the user who submitted it. More than just a set of changes, changelists are also atomic. That is, changelists don't overlap with each other. Two changelists might be submitted at the same time, but the server will ensure that processing is completed for one changelist entirely before it starts processing the second changelist; changelists will never be intermingled by the server. Furthermore, once the server has successfully completed processing a changelist that changelist becomes immutable. That is, users can't add, remove, or modify any of the file changes represented by the changelist.

A reasonable analogy is to think of a changelist as a transaction. The Perforce equivalent is that if your changelist contains ten files, then either all ten will be submitted, or none of them. You will never get only a part of the total files submitted.

Many Perforce customers have servers handling thousands of users, and millions or more changelists. Changelists are ideal reference points for build systems, release processes, validation audits, and myriad other uses where a reproducible and verifiable set of managed sources is required.

In the following diagram, two files from the workspace are submitted as a single changelist to the repository. The changelist will automatically be assigned a unique number from an increasing sequence by the server. We cover this in more detail in Chapter 4, Changelists, including changelist states such as pending and submitted.