Helix Core is now P4 and Helix Swarm is now P4 Code Review. Product user interfaces will be updated soon. Learn more >>

Documentation | 2025.3

# Glossary

A
- access level
  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.
- admin access
  An access level that gives the user permission to use privileged commands.
- archive depot
  A special depot into which versioned files (also known as archive files) can be transferred. See also 'depot'.
- archive files
  Versioned files that users submitted to a depot.
B
- base
  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'.
- binary file type
  A file type assigned to a non-text file. By default, the contents of each binary revision are stored in full.
- branch
  (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.
- branch form
  The form that appears when you use the 'p4 branch' command to create or modify a branch specification.
- branch view
  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.
- broker
  A P4 component that can apply rules and scripts based on incoming commands before passing them to a designated P4 Server.
C
- central 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'.
- change review
  The process of sending email to users who have registered that they want to know about or watch changelists that include the specified files.
- changelist
  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.
- changelist number
  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.
- check in
  To submit a file to the depot.
- check out
  To designate one or more files, or a stream, for edit.
- checkpoint
  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.
- classic depot
  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'.
- client form
  The form you use to define a client workspace, such as with the 'p4 client' or 'p4 workspace' commands.
- client root
  The topmost directory of a client workspace.
- client syntax
  The way of indicating the location of files in the client workspace that, unlike 'depot syntax', begins with //workspaceName/
- client workspace
  Directories on your machine where you work on file revisions that are managed by P4 Server.
- code review
  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.
- codeline
  A set of files that evolve collectively. One codeline can be branched from another, such as a release codeline from a development codeline.
- comment
  Feedback provided in P4 Code Review on a on all or part of a changelist, review, or job.
- commit server
  The innermost P4 Server server in a topology with one or more edge servers.
- conflict
  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.
- counter
  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'.
D
- database
  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.
- default changelist
  The unnumbered pending changelist that is automatically created when a file is opened for add, edit, or delete.
- deleted file
  A file with the head revision marked as deleted. Previous revisions of the file are still available. See also 'head revision' and 'obliterate'.
- delta transfer
  A P4 Server feature that might boost performance by sending over the network only the parts of a file that have changed.
- depot
  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.
- depot root
  The topmost directory for a depot.
- depot side
  The first part of a client view mapping, specifying the location of files in a depot. See client side.
- depot syntax
  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/
- diff
  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.
- distribution server
  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.
E
- edge server
  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.
- exclusionary mapping
  A view mapping that excludes specific files or directories.
- extension
  Custom logic that runs in a Lua engine embedded into the P4 Server. Extensions are an alternative to triggers. See the P4 Extensions Documentation.
F
- file conflict
  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.
- file pattern
  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'.
- file revision
  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
- file specification
  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.
- file type
  An attribute that determines how the server stores and diffs a particular file. Examples of file types: binary, text, and unicode.
- form
  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.
- forwarding replica
  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.
G
- Git Connector
  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'.
- graph depot
  A depot of type graph that is used to store Git repos managed by P4 Server. See also Git Connector and classic depot.
H
- have list
  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.
- head revision
  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.
- heartbeat
  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.
- hybrid workspace
  A client workspace that supports both repos of type graph (see also 'Git Connector') and the classic P4 file revision model.
I
- integrate
  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.
J
- journal
  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.
- journal notes
  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.
- journal rotation
  The process of renaming the current journal to a numbered journal file as part of a checkpoint.
- journaling
  The process of recording changes made to the server database. See also 'metadata'.
L
- label
  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
- lazy copy
  A method to conserve disk space by referencing files instead of duplicating their content.
- librarian
  A subsystem of the server that stores, manages, and provides the archive files to other subsystems of the server. See also 'archive files'.
- license file
  A file that ensures that the number of users on your site does not exceed the number for which you have paid.
- list access
  A protection level that enables you to run reporting commands but prevents access to the contents of files.
- local syntax
  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.
- lock
  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.
- log
  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.
M
- mapping
  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'.
- merge
  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.
- merge file
  A file generated from two conflicting file revisions.
- metadata
  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.
N
- nonexistent revision
  An empty revision of a file that results from deleting a file or syncing to the #none revision.
- numbered changelist
  A changelist to which the server has assigned a number. This is distinct from the default of an unnumbered pending changelist.
O
- obliterate
  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.
- offline database
  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.
- opened file
  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.
- owner
  The user who created a particular client, branch, or label.
P
- P4 Code Review
  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)
- P4 Server
  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.
- p4d
  The binary file (p4d.exe on Windows) that runs P4 Server to manage depot files (versioned files) and the metadata of the server database.
- pending changelist
  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.
- protections
  The permissions stored in the P4 Server protections table. User permissions can be managed with the 'p4 protect' command and the P4Admin application.
- proxy server
  A P4 server application that caches versioned files and can deliver them to clients on behalf of a P4 Server.
R
- real-time performance counters
  Various server-wide counters providing performance data in real time.
- remote depot
  A depot located on a different P4 Server that the current P4 Server can access.
- replica
  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.
- repo
  The container of files that the Git Connector caches or mirrors from Git users. See also 'graph depot'.
- resolve
  The process you use to manage the differences between two revisions of a file, or two versions of a stream spec.
- revert
  To discard changes you made to a file in your client workspace without submitting the changes to the depot.
- revision number
  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
- revision range
  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.
- revision specification
  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.
S
- shelve
  The process of temporarily storing files in the server without checking in a changelist. Shelves are often used for reviews.
- stream
  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.
- stream depot
  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'.
- stream hierarchy
  The set of parent-to-child relationships between streams in a stream depot.
- stream view
  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.
- submit
  To send a pending changelist from the client workspace to the depot.
- super access
  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.
- sync
  To copy file revisions from the depot to your client workspace.
T
- target server
  The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'.
- topology
  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.
- trigger
  A script to customize server behavior when specific conditions are met.
- two-way merge
  The process of combining two file revisions. In a two-way merge, you can see differences between the files.
- typemap
  A table in which you assign file types to files. For example, pdf is typically mapped to binary as opposed to text.
U
- unload depot
  A special depot for infrequently used metadata or to facilitate reloading workspaces that have been moved to a different server.
- upstream 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'.
- user
  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.
V
- versioned files
  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'.
- view
  A description of the relationship between two sets of files. See workspace view, label view, branch view.
W
- workspace
  See client workspace.
- workspace view
  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.

Your search for returned results