Helix Core is now P4 and Helix Swarm is now P4 Code Review. Learn more >>

Documentation | 2025.2

# Glossary

A
- access level
  A permission assigned to a user to control which commands the user can execute. See also the 'protections' entry in this glossary and the 'p4 protect' command in the P4 Command Reference.
- admin access
  An access level that gives the user permission to privileged commands, usually super privileges.
- APC
  The Alternative PHP Cache, a free, open, and robust framework for caching and optimizing PHP intermediate code.
- archive
  1. For replication, versioned files (as opposed to database metadata). 2. For the 'p4 archive' command, a special depot in which to copy the server data (versioned files and metadata).
- atomic change transaction
  Grouping operations affecting a number of files in a single transaction. If all operations in the transaction succeed, all the files are updated. If any operation in the transaction fails, none of the files are updated.
- avatar
  A visual representation of a user or group. Avatars are used in P4 Code Review to show involvement in (or ownership of) projects, groups, changelists, reviews, comments.
B
- base
  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. For checked out streams: The public have version from which the checked out version is derived.
- binary file type
  A P4 Server file type assigned to a non-text file. By default, the contents of each revision are stored in full, and file revision is stored in compressed format.
- 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 Helix Swarm with the projects they are part of, add the "branch" paths in the Swarm project. (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 mapping
  Specifies how a branch is to be created or integrated by defining the location, the files, and the exclusions of the original codeline and the target codeline. The branch mapping is used by the integration process to create and update branches.
- branch view
  A specification of the branching relationship 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. This is the same as branch mapping.
- broker
  P4 Broker, a server process that intercepts commands to the P4 Server and is able to run scripts on the commands before sending them to the P4 Server.
C
- change review
  The process of sending email to users who have registered their interest in changelists that include specified files in the depot.
- changelist
  A list of files, their version numbers, the changes made to the files, and a description of the changes made. A changelist is the basic unit of versioned work in P4 Server. The changes specified in the changelist are not stored in the depot until the changelist is submitted to the depot. See also atomic change transaction and changelist number.
- changelist form
  The form that appears when you modify a changelist using the 'p4 change' command.
- 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 P4 Server 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 default depot, 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 name
  A name that uniquely identifies the current client workspace. Client workspaces, labels, and branch specifications cannot share the same name.
- client root
  The topmost (root) directory of a client workspace. If two or more client workspaces are located on one machine, they should not share a client root directory.
- client side
  The right-hand side of a mapping within a client view, specifying where the corresponding depot files are located in the client workspace.
- client workspace
  Directories on your machine where you work on file revisions that are managed by P4 Server. By default, this name is set to the name of the machine on which your client workspace is located, but it can be overridden. Client workspaces, labels, and branch specifications cannot share the same name.
- code review
  A process in P4 Code Review 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, allowing each set of files to evolve separately.
- comment
  Feedback provided in P4 Code Review on a changelist, review, job, or a file within a changelist or review.
- commit server
  The innermost P4 Server in a multi-server topology that includes edge servers. The commit server processes submitted files (changelists), global workspaces, and promoted shelves.
- 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. This type of conflict occurs when the comparison of two files to a base yields different results, indicating that the files have been changed in different ways. In this case, the merge cannot be done automatically and must be resolved manually. See file conflict.
- copy up
  A P4 Server best practice to copy (and not merge) changes from less stable lines to more stable lines. See also merge.
- counter
  A numeric variable used to track variables such as changelists, checkpoints, and reviews.
D
- database
  The database in the P4ROOT directory contains db.* files with metadata that the P4 Server uses to operate on versioned files, users, protections, streams, changelists, and more.
- default changelist
  The changelist used by a file add, edit, or delete, unless a numbered changelist is specified. A default pending changelist is created automatically when a file is opened for edit.
- deleted file
  In P4 Server, a file with its head revision marked as deleted. Older revisions of the file are still available. See also "obliterate".
- delta
  The differences between two files.
- 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, including deleted files (but not obliterated files). There can be multiple depots on a single installation.
- depot root
  The topmost (root) directory for a depot.
- depot side
  The left side of any client view mapping, specifying the location of files in a depot.
- depot syntax
  P4 Server syntax for specifying the location of files in the depot. Depot syntax begins with: //depot/
- diff
  (noun) A set of lines that do not match when two files, or stream versions, are compared. A conflict is a pair of unequal diffs between each of two files and a base, or between two versions of a stream. (verb) To compare the contents of files or file revisions, or of stream versions. See also conflict.
E
- edge server
  A replica server that is part of an edge/commit system that is able to process most read/write commands, including 'p4 integrate', and also deliver versioned files (depot files).
- exclusionary access
  A permission that denies access to the specified files.
- exclusionary mapping
  A view mapping that excludes specific files or directories.
- extension
  Custom logic that runs in a Lua engine embedded into the Helix Server. P4 Extensions are a recent alternative to triggers, which require a runtime that is external to the server. 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. Also, an attempt to submit a file that is not an edit of the head revision of the file in the depot, which typically occurs when another user opens the file for edit after you have opened the file for edit.
- file pattern
  P4 Server command line syntax that enables you to specify files using wildcards.
- file repository
  The server's copy of all files, which is shared by all users. In P4 Server, this is called the depot.
- 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 (#), for example testfile#3.
- file tree
  All the subdirectories and files under a given root directory.
- file type
  An attribute that determines how P4 Server stores and diffs a particular file. Examples of file types are text and binary.
- fix
  A job that has been closed in a changelist.
- form
  A screen displayed by certain P4 Server commands. For example, you use the change form to enter comments about a particular changelist to verify the affected files.
- forwarding replica
  A replica server that can process read-only commands and deliver versioned files (depot files). One or more replicate servers can significantly improve performance by offloading some of the master server load. In many cases, a forwarding replica can become a disaster recovery server.
G
- Git Connector
  The Git Connector component of Git Connector interacts with your native Git clients. It serves Git commands and performs all Git repo operations. See "hybrid workspace".
- Git Fusion
  (No longer offered to new customers) A Perforce product that integrates Git with Helix, offering enterprise-ready Git repository management, and workflows that allow Git and P4 Server users to collaborate on the same projects using their preferred tools.
- graph depot
  A depot of type graph that is used to store Git repos in the P4 Server. See also Git Connector and classic depot.
- group
  A feature in P4 Server that makes it easier to manage permissions for multiple users.
H
- have list
  The list of file revisions currently in the client workspace.
- 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
  A process that allows one server to monitor another server, such as a standby server monitoring the master server (see the p4 heartbeat command).
- hybrid workspace
  A workspace that supports both repos of type graph (see "Git Connector"), and the P4 file revision model.
I
- integrate
  To compare two sets of files (for example, two codeline branches) and determine which changes in one set apply to the other, determine if the changes have already been propagated, and propagate any outstanding changes from one set to another.
J
- job
  A user-defined unit of work tracked by P4 Server. The job template determines what information is tracked. The template can be modified by the P4 Server system administrator. A job describes work to be done, such as a bug fix. Associating a job with a changelist records which changes fixed the bug.
- job specification
  A form describing the fields and possible values for each job stored in the P4 Server machine.
- journal
  A file containing a record of every change made to the P4 Server’s metadata since the time of the last checkpoint. This file grows as each P4 Server transaction is logged. The file should be automatically truncated and renamed into a numbered journal when a checkpoint is taken.
- journal rotation
  The process of renaming the current journal to a numbered journal file.
- journaling
  The process of recording changes made to the P4 Server’s metadata.
L
- label
  A named list of user-specified file revisions.
- label view
  The view that specifies which filenames in the depot can be stored in a particular label.
- lazy copy
  A method used by P4 Server to make internal copies of files without duplicating file content in the depot. A lazy copy points to the original versioned file (depot file). Lazy copies minimize the consumption of disk space by storing references to the original file instead of copies of the file.
- librarian
  The librarian subsystem of the server stores, manages, and provides the archive files to other subsystems of the P4 server.
- license file
  A file that ensures that the number of P4 Server 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 depot
  Any depot located on the currently specified P4 Server.
- local syntax
  The syntax for specifying a filename that is specific to an operating system.
- 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
  Error output from the P4 Server. To specify a log file, set the P4LOG environment variable or use the p4d -L flag when starting the service.
M
- mapping
  A single line in a view, consisting of a left side and a right side that 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.
- master server
  The innermost P4 server in a multi-server topology. In the server spec, the Services field must be set to 'commit-server' for edge-commit architecture, and is typically set to 'standard' for master-replica architecture.
- MDS checksum
  The method used by P4 Server to verify the integrity of versioned files (depot files).
- merge
  1. To create new files from existing files, preserving their ancestry (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 like P4 Merge.
- merge file
  A file generated by the P4 Server from two conflicting file revisions.
- metadata
  The data stored by the P4 Server that describes the files in the depot, the current state of client workspaces, protections, users, labels, and branches. Metadata is stored in the Perforce database and is separate from the archive files that users submit.
- modification time or modtime
  The time a file was last changed.
- MPM
  Multi-Processing Module, a component of the Apache web server that is responsible for binding to network ports, accepting requests, and dispatch operations to handle the request.
N
- nonexistent revision
  A completely empty revision of any file. Syncing to a nonexistent revision of a file removes it from your workspace. An empty file revision created by deleting a file and the #none revision specifier are examples of nonexistent file revisions.
- numbered changelist
  A pending changelist to which P4 Server has assigned a number.
O
- obliterate
  The p4 obliteratre command permanently removes files and their history from the depot. See also "deleted file".
- 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 you have checked out in your client workspace as a result of a Helix Core Server operation (such as an edit, add, delete, integrate). Opening a file from your operating system file browser is not tracked by Helix Core Server.
- owner
  The P4 Server user who created a particular client, branch, or label.
P
- p4
  1. The P4 Server command line program. 2. The command you issue to execute commands from the operating system command line.
- P4 Server
  The P4 Server depot and metadata; also, the program that manages the depot and metadata, also called P4 Server.
- p4d
  The program that runs the P4 Server; p4d manages depot files and metadata.
- P4PHP
  The PHP interface to the Helix API, which enables you to write PHP code that interacts with a P4 Server machine.
- PECL
  PHP Extension Community Library, a library of extensions that can be added to PHP to improve and extend its functionality.
- pending changelist
  A changelist that has not been submitted.
- Perforce TeamHub
  A Perforce management platform for code and artifact repository. TeamHub offers built-in support for Git, SVN, Mercurial, Maven, and more.
- project
  In P4 Code Review, a group of P4 Server users who are working together on a specific codebase, defined by one or more branches of code, along with options for a job filter, automated test integration, and automated deployment.
- protections
  The permissions stored in the P4 Server’s protections table.
- proxy server
  A P4 Server that stores versioned files. A proxy server does not perform any commands. It serves versioned files to P4 Server clients.
R
- RCS format
  Revision Control System format. Used for storing revisions of text files in versioned files (depot files). RCS format uses reverse delta encoding for file storage. P4 Server uses RCS format to store text files. See also reverse delta storage.
- read access
  A protection level that enables you to read the contents of files managed by P4 Server but not make any changes.
- remote depot
  A depot located on another P4 Server accessed by the current P4 Server.
- replica
  A P4 Server that automatically maintains a full or partial copy of metadata and none, some, or all of the related file archives by copying data from a master P4 Server using 'p4 pull' or 'p4 journalcopy'.
- repo
  A graph depot contains one or more repos, and each repo contains files from Git users.
- reresolve
  The process of resolving a file after the file is resolved and before it is submitted.
- resolve
  The process you use to manage the differences between two revisions of a file, or two versions of a stream. You can choose to resolve file conflicts by selecting the source or target file to be submitted, by merging the contents of conflicting files, or by making additional changes. To resolve stream conflicts, you can choose to accept the public source, accept the checked out target, manually accept changes, or combine path fields of the public and checked out versions while accepting all other changes made in the checked out version.
- reverse delta storage
  The method that P4 Server uses to store revisions of text files. P4 Server stores the changes between each revision and its previous revision, plus the full text of the head revision.
- revert
  To discard the changes you have made to a file in the client workspace before a submit.
- review access
  A special protections level that includes read and list accesses and grants permission to run the p4 review command.
- review daemon
  A program that periodically checks the P4 Server machine to determine if any changelists have been submitted. If so, the daemon sends an email message to users who have subscribed to any of the files included in those changelists, informing them of changes in files they are interested in.
- revision number
  A number indicating which revision of the file is being referred to, typically designated with a pound sign (#).
- revision range
  A range of revision numbers for a specified file, specified as the low and high end of the range. For example, myfile#5,7 specifies revisions 5 through 7 of myfile.
- revision specification
  A suffix to a filename that specifies a particular revision of that file. Revision specifiers can be revision numbers, a revision range, change numbers, label names, date/time specifications, or client names.
- RPM
  RPM Package Manager. A tool, and package format, for managing the installation, updates, and removal of software packages for Linux distributions such as Red Hat Enterprise Linux, the Fedora Project, and the CentOS Project.
S
- server data
  The combination of server metadata (the P4 Server database) and the depot files (your organization's versioned source code and binary assets).
- server root
  The topmost directory in which p4d stores its metadata (db.* files) and all versioned files (depot files or source files). To specify the server root, set the P4ROOT environment variable or use the p4d -r flag.
- service
  In the P4 Server, the shared versioning service that responds to requests from P4 Server client applications. The P4 Server (p4d) maintains depot files and metadata describing the files and also tracks the state of client workspaces.
- shelve
  The process of temporarily storing files in the P4 Server without checking in a changelist.
- status
  For a changelist, a value that indicates whether the changelist is new, pending, or submitted. For a job, a value that indicates whether the job is open, closed, or suspended. You can customize job statuses. For the 'p4 status' command, by default the files opened and the files that need to be reconciled.
- storage record
  An entry within the db.storage table to track references to an archive file.
- stream
  A "branch" with built-in rules that determine what changes should be propagated to files in a stream depot, and in what order they should be propagated. A stream spec defines a stream. A user creates a stream spec by using either the "p4 stream" command or in P4V with File > New 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. Has structured branching, unlike the free-form branching of a "classic" depot. Uses the file revision model, not the graph model. 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 stream view is defined by the Paths, Remapped, and Ignored fields of the stream specification. (See Form Fields in the p4 stream command)
- submit
  To send a pending changelist into the P4 Server depot for processing.
- super access
  An access level that gives the user permission to run every P4 Server command, including commands that set protections, install triggers, or shut down the service for maintenance.
- symlink file type
  A P4 Server file type assigned to symbolic links. On platforms that do not support symbolic links, symlink files appear as small text files.
- sync
  To copy a file revision (or set of file revisions) from the P4 Server depot to a client workspace.
T
- target file
  The file that receives the changes from the donor file when you integrate changes between two codelines.
- text file type
  P4 Server file type assigned to a file that contains only ASCII text, including Unicode text. See also binary file type.
- theirs
  The revision in the depot with which the client file (your file) is merged when you resolve a file conflict. When you are working with branched files, theirs is the donor file.
- three-way merge
  The process of combining three file revisions. During a three-way merge, you can identify where conflicting changes have occurred and specify how you want to resolve the conflicts.
- topology
  The set of P4 services deployed in a multi-server installation, which might include commit-server, edge servers, standby servers, proxies, brokers, and more.
- trigger
  A script that is automatically invoked by P4 Server when various conditions are met. (See "P4 Server Administration Documentation" on "Triggers".)
- 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 P4 Server in which you assign file types to files.
U
- user
  The identifier that P4 Server uses to determine who is performing an operation. The three types of users are standard, service, and operator.
V
- versioned files
  Source files stored in the P4 Server 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
- wildcard
  A special character used to match other characters in strings. The following wildcards are available in P4 Server: * matches anything except a slash; ... matches anything including slashes; %%0 through %%9 is used for parameter substitution in views.
- workspace
  See client workspace.
- workspace view
  A set of mappings that specifies the correspondence between file locations in the depot and the client workspace.
- write access
  A protection level that enables you to run commands that alter the contents of files in the depot. Write access includes read and list accesses.
X
- XSS
  Cross-Site Scripting, a form of web-based attack that injects malicious code into a user's web browser.
Y
- yours
  The edited version of a file in your client workspace when you resolve a file. Also, the target file when you integrate a branched file.

Your search for returned results