Glossary
-
A permission assigned to a user to control which commands the user can run. See also the 'protections' entry in this glossary and the 'p4 protect' command in the P4 CLI Reference.
-
An access level that gives the user permission to use privileged commands.
-
A special depot into which versioned files (also known as archive files) can be transferred. See also 'depot'.
-
Versioned files that users submitted to a depot.
-
1. For files: The file revision that contains the most common edits or changes among the file revisions in the source file and target file paths. 2. For checked out streams: The public 'have' version from which the checked out version is derived. See also 'have list'.
-
A file type assigned to a non-text file. By default, the contents of each binary revision are stored in full.
-
(noun) A set of related files that exist at a specific location in the P4 depot as a result of being copied to that location, as opposed to being added to that location. A group of related files is often referred to as a codeline. To associate code reviews in P4 Code Review (formerly Helix Swarm) with the projects they are part of, add the 'branch' paths in the P4 Code Reviewproject. (verb) To create a codeline by copying another codeline with the 'p4 integrate', 'p4 copy', or 'p4 populate' command.
-
The form that appears when you use the 'p4 branch' command to create or modify a branch specification.
-
A specification of the branching relationship (branch mapping) between two codelines in the depot. Each branch view has a unique name and defines how files are mapped from the originating codeline to the target codeline.
-
A P4 component that can apply rules and scripts based on incoming commands before passing them to a designated P4 Server.
-
The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'.
-
The process of sending email to users who have registered that they want to know about or watch changelists that include the specified files.
-
The changes to files or stream specifications along with metadata, such as the list of changed files, their version numbers, the submitter of the changelist, and the submitter's description of the changes. A changelist is the unit of versioned work.
-
An integer that identifies a changelist. Submitted changelist numbers are ordinal (increasing), but not necessarily consecutive. For example: 103, 105, 108, 109. A pending changelist number might be assigned a different value upon submission.
-
To submit a file to the depot.
-
To designate one or more files, or a stream, for edit.
-
A backup copy of the underlying metadata at a particular moment in time. A checkpoint can recreate db.user, db.protect, and other db.* files. See also metadata.
-
A repository of P4 files that is not streams-based. Uses the Perforce file revision model, not the graph model. The default depot name is depot. See also 'stream depot' and 'graph depot'.
-
The form you use to define a client workspace, such as with the 'p4 client' or 'p4 workspace' commands.
-
The topmost directory of a client workspace.
-
The way of indicating the location of files in the client workspace that, unlike 'depot syntax', begins with //workspaceName/
-
Directories on your machine where you work on file revisions that are managed by P4 Server.
-
A process in P4 Code Review (formerly Helix Swarm) by which other developers can see your code, provide feedback, and approve or reject your changes.
-
A set of files that evolve collectively. One codeline can be branched from another, such as a release codeline from a development codeline.
-
Feedback provided in P4 Code Review on a on all or part of a changelist, review, or job.
-
The innermost P4 Server server in a topology with one or more edge servers.
-
1. A situation where two users open the same file for edit. One user submits the file, after which the other user cannot submit unless the file is resolved. 2. A resolve where the same line is changed when merging one file into another.
-
A persistent numeric or textual variable that records details relevant to the functioning of a P4 Server instance or scripts that access that instance. See 'real-time performance counters'.
-
The set of db.* files in the P4ROOT directory that contain metadata that the P4 Server uses to operate on versioned files, users, protections, streams, changelists, and more.
-
The unnumbered pending changelist that is automatically created when a file is opened for add, edit, or delete.
-
A file with the head revision marked as deleted. Previous revisions of the file are still available. See also 'head revision' and 'obliterate'.
-
A P4 Server feature that might boost performance by sending over the network only the parts of a file that have changed.
-
A file repository hosted on the P4 Server. A depot is the top-level unit of storage for versioned files, which are also known as depot files, archive files, or source files. It contains all versions of all files ever submitted to the depot. Except for obliterated files, any version of any file can be restored, including deleted files, but not obliterated files. An installation can have multiple depots, and they might be of different types, such as a local depot and a stream depot.
-
The topmost directory for a depot.
-
The first part of a client view mapping, specifying the location of files in a depot. See client side.
-
The syntax for specifying the location of files in the P4 Server depot as opposed to in the user's client workspace. Depot syntax begins with //depotName/
-
1: A set of lines that do not match when two files, or stream versions, are compared. 2: To compare the contents of files or file revisions, or of stream versions. See conflict.
-
A P4 Server that allows a limited set of content and history to be exposed to third parties, without exposing the main server or the internal network.
-
A server that is part of a commit-edge environment that can independently support work in progress for locally-bound clients, thereby reducing the load on the commit server.
-
A view mapping that excludes specific files or directories.
-
Custom logic that runs in a Lua engine embedded into the P4 Server. Extensions are an alternative to triggers. See the P4 Extensions Documentation.
-
In a three-way file merge, a situation in which two revisions of a file differ from each other and from their base file. A file conflict can occur when multiple users have the same file opened for edit.
-
A definition of a set of files that is made up of a file spec that might include wildcards and a revision specification. See 'revision specification'.
-
A specific version of a file within the depot. Each revision is assigned a number, in sequence. Any revision can be accessed in the depot by its revision number, preceded by a pound sign (#). Example: testfile#3
-
Syntax that enables you to specify a set of files. A file spec might include wildcards and special characters for a range of dates, revisions, or changelists. File specs are also used to define the mappings of a client workspace and to specify a label.
-
An attribute that determines how the server stores and diffs a particular file. Examples of file types: binary, text, and unicode.
-
A screen displayed by certain P4 Server commands to create a specification (spec) by assigning values to fields. For example, you use the client form to define a client workspace mappings. Commonly used forms include Branch, Change, Client, Depot, Group, Label, Server, Stream, and User.
-
A P4 server that processes reporting (read) commands but forwards update (write) commands to the central server. Forwarding replicas can reduce the workload of the central server and be used as a backup server for disaster recovery.
-
A component of P4 Server that enables you mirror, cache, or replicate a Git repository into a P4 Server repo in a graph depot. See also 'hybrid workspace'.
-
A depot of type graph that is used to store Git repos managed by P4 Server. See also Git Connector and classic depot.
-
The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has.
-
The most recent revision of a file within the depot. Because file revisions are numbered sequentially, this revision is the highest-numbered revision of that file.
-
For failover, a process that allows one server to monitor another server, such as a standby server monitoring its upstream server so that it is prepared to take over the role of the upstream server. See the 'p4 heartbeat' command.
-
A client workspace that supports both repos of type graph (see also 'Git Connector') and the classic P4 file revision model.
-
To compare two sets of files and determine which changes to propagate. A typical use case is to integrate between a development branch and a release branch.
-
A file containing a record of every change made to the metadata since the time of the last checkpoint. This file grows as each transaction is logged.
-
Entries added to journals and checkpoints that provide information for subsequent users of the journal or checkpoint. For example, replica servers might take action based on the journal notes they process.
-
The process of renaming the current journal to a numbered journal file as part of a checkpoint.
-
The process of recording changes made to the server database. See also 'metadata'.
-
A special filespec that gives a meaningful name to a set of file revisions. For example, the @Release2.3-August-2025 label is easier to remember than //depot/project/...@48296
-
A method to conserve disk space by referencing files instead of duplicating their content.
-
A subsystem of the server that stores, manages, and provides the archive files to other subsystems of the server. See also 'archive files'.
-
A file that ensures that the number of users on your site does not exceed the number for which you have paid.
-
A protection level that enables you to run reporting commands but prevents access to the contents of files.
-
The way of indicating the location of files that, unlike 'depot syntax', is specific to the local operating system. This syntax is used as the second part of the client workspace mapping, after the depot syntax. Examples: /staff/maria/myworkspace/file.c for Linux and c:\staff\maria\myworkspace\file.c for Windows.
-
1. A file lock that prevents other clients from submitting the locked file. Files are unlocked with the 'p4 unlock' command or by submitting the changelist that contains the locked file. 2. A database lock that prevents another process from modifying the database db.* file.
-
P4 Server supports the standard log, which is human-readable, as well as structured logs in a comma-separated value (CSV) format. The P4LOG environment variable specifies the log file for events, including errors. The human-readable P4AUDIT environment variable specifies the log file that records file transfers to users. Structured log files are typically processed by external tools. To learn more, see 'Logging" in P4 Server Administration Documentation.
-
A single line in a view definition, consisting of a left side, a blank space, and a right side. The mappings specify the correspondences between files in the depot and files in a client, label, or branch. See also 'workspace view', 'branch view', and 'label view'.
-
1. To create new files from existing files, preserving their history when branching. 2. To propagate changes from one set of files to another. 3. The process of combining the contents of two conflicting file revisions into a single file, typically using a merge tool, such as P4 Merge.
-
A file generated from two conflicting file revisions.
-
Information that P4 Server maintains, such as who created file revisions in the depot, whether the file is a 'lazy copy,, the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the 'archive files' that users submit from their client workspace into the depot.
-
An empty revision of a file that results from deleting a file or syncing to the #none revision.
-
A changelist to which the server has assigned a number. This is distinct from the default of an unnumbered pending changelist.
-
Permanent removal of files and their history from the depot. The 'p4 obliterate' command makes it impossible to recover the file, unlike the 'p4 delete' command, which preserves the previous revisions.
-
A copy of a P4 Server database that is kept up to date by manual or scripted processes that replay journals from a P4 Server.
-
A file in your client workspace that you have checked out because you intend to edit, add, delete, or branch the file. Opening a file from your operating system file browser is not tracked by P4 Server.
-
The user who created a particular client, branch, or label.
-
A web-based code review tool for P4. Contributors share files, comment, suggest tasks, vote up or down, and submit final work. (Formerly Helix Swarm)
-
The program that manages the depot files, the metadata associated with those files, as well as the permissions the administrator grants to specific users and groups.
-
The binary file (p4d.exe on Windows) that runs P4 Server to manage depot files (versioned files) and the metadata of the server database.
-
A unit of versioned work that is not submitted. A changelist is created when you check out any file. A changelist is pending until you submit or revert the change.
-
The permissions stored in the P4 Server protections table. User permissions can be managed with the 'p4 protect' command and the P4Admin application.
-
A P4 server application that caches versioned files and can deliver them to clients on behalf of a P4 Server.
-
Various server-wide counters providing performance data in real time.
-
A depot located on a different P4 Server that the current P4 Server can access.
-
A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery.
-
The container of files that the Git Connector caches or mirrors from Git users. See also 'graph depot'.
-
The process you use to manage the differences between two revisions of a file, or two versions of a stream spec.
-
To discard changes you made to a file in your client workspace without submitting the changes to the depot.
-
An integer indicating a specific file revision. For example, if the file name is readme.txt and the revision number is 5, the file name would include a pound sign prefix and the number 5, such as readme.txt#5
-
A range of revision numbers for a file, specified as the low and high end of the range. For example, myfile.txt#5,7 specifies revisions 5 through 7 of myfile.txt.
-
A suffix to a file name that specifies one or more file revisions. Revision specifiers can be revision numbers, a revision range, change numbers, label names, date/time specifications, or client names.
-
The process of temporarily storing files in the server without checking in a changelist. Shelves are often used for reviews.
-
An enhanced type of branch with a dedicated view for clients of the stream (see 'stream view') and built-in rules that determine how changes flow across the stream depot (see 'stream hierarchy'). A stream specification defines a stream. In P4V, stream specs are visible in the Streams Graph and the Streams tab.
-
A depot used with streams and stream clients. A stream depot has structured branching, unlike the free-form branching of other depot types. See also 'classic depot' and 'graph depot'.
-
The set of parent-to-child relationships between streams in a stream depot.
-
A dedicated view shared by all clients of the stream. A stream view is defined by the Paths, Remapped, and Ignored fields of the stream specification.A stream view can be seen with the 'p4 stream -ov' command.
-
To send a pending changelist from the client workspace to the depot.
-
The highest access level, which gives this user permission to run every command of P4 Server, including commands that set protections, install triggers, shut down the service for maintenance, as well as perform failover and failback.
-
To copy file revisions from the depot to your client workspace.
-
The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'.
-
Data about the set of P4 services deployed in a multi-server installation, which might include a commit server, edge servers, standby servers, proxies, and brokers. P4Admin's Topology tab visualizes the topology and supports exporting the details, which might help for troubleshooting.
-
A script to customize server behavior when specific conditions are met.
-
The process of combining two file revisions. In a two-way merge, you can see differences between the files.
-
A table in which you assign file types to files. For example, pdf is typically mapped to binary as opposed to text.
-
A special depot for infrequently used metadata or to facilitate reloading workspaces that have been moved to a different server.
-
Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'.
-
The identifier that P4 Server uses to determine who is performing an operation. The three types of users are standard (also includes the user with super access), service, and operator. Service users and operator users are restricted to a narrow subset of commands but do not consume a license.
-
Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'.
-
A description of the relationship between two sets of files. See workspace view, label view, branch view.
-
See client workspace.
-
A set of mappings that specifies the correspondence between file locations in the depot and the client workspace. Each row in the workspace view consists of a pair of filespecs, first a depot filespec, then white space, and finally a filespec that shows a workspace location relative to the workspace root.
A
B
C
D
E
F
G
H
I
J
L
M
N
O
P
R
S
T
U
V
W