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 Helix Core Command-Line (P4) Reference.
-
An access level that gives the user permission to privileged commands.
-
A special depot into which versioned files (also known as archive files) can be transferred.
-
Versioned files that users have submitted to a depot.
-
Grouping operations affecting multiple 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.
-
A visual representation of a user or group. Avatars are used in Swarm to show involvement in (or ownership of) projects, groups, changelists, reviews, comments.
-
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.
-
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 Helix Core 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.
-
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 Helix Core component that is able to apply rules and scripts based on incoming commands before passing them to a designated Helix Core Server.
-
The process of sending email to users who have registered their interest in changelists that include specified files in the depot.
-
The changes to files or stream specifications along with metadata, such as the list of changed files, their version numbers, who submitted the changelist to the depot, and the submitter's description of the changes. A changelist is the unit of versioned work. See also atomic change transaction and changelist number.
-
The form that appears when you modify a changelist with the 'p4 change' command.
-
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 Helix Core 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.
-
The form you use to define a client workspace, such as with the 'p4 client' or 'p4 workspace' commands.
-
A name that uniquely identifies the current client workspace. Client workspaces, labels, and branch specifications cannot share the same name.
-
The topmost directory of a client workspace. If two or more client workspaces are located on one machine, they should not share a client root directory.
-
The second part of a client workspace mapping, separated by a space from the depot side. The client side specifies where depot files are copied to when syncing to get the latest versions.
-
The syntax for specifying the location of files in the client workspace as opposed to the depot. Client syntax begins with //workspaceName/
-
Directories on your machine where you work on file revisions that are managed by Helix Core 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.
-
A process in 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. This allowing each set of files to evolve separately.
-
Feedback provided in Helix Swarm on a changelist, review, job, or a file within a changelist or review.
-
The innermost Helix Core Server Server in a multi-server topology that implements the protocols required by 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. 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.
-
A best practice is to copy (and not merge) changes from less stable codelines to more stable codelines. See also merge.
-
A numeric variable used to track variables such as changelists, checkpoints, and reviews.
-
The database in the P4ROOT directory contains db.* files with metadata that the Helix Core 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. Older revisions of the file are still available. See also 'head revision' and 'obliterate'.
-
The differences between two files.
-
A file repository hosted on the Helix Core 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 depot as opposed to the client workspace. Depot syntax begins with //depotName/
-
(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 conflict.
-
A Helix Core 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 is able to independently support work in progress for locally-bound clients, thereby reducing the load on the commit server.
-
A permission that denies access to the specified files.
-
A view mapping that excludes specific files or directories.
-
Custom logic that runs in a Lua engine embedded into the Helix Core Server and that does not require a runtime that is external to the server. Extensions are an alternative to triggers. See the Helix Core Extensions Developer Guide.
-
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 conflict that must be resolved when attempting to submit a file that is not an edit of the head revision of the file in the depot. 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 (#) and testfile#3 would be an example.
-
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.
-
All the subdirectories and files under a given root directory.
-
An attribute that determines how the server stores and diffs a particular file. Examples of file types are text and binary.
-
A screen displayed by certain Helix Core Server commands. For example, you use the change form to enter comments about a particular changelist to verify the affected files. Similarly, you use the client form to define a client workspace.
-
A Helix Core server that processes reporting (read) commands but forwards update (write) commands to the master server. One or more forwarding replicas can improve performance by reducing the workload of the master server. Can be used as a backup server for disaster recovery.
-
A component of Helix Core Server that enables you mirror, cache, or replicate a Git repository into a Helix Core Server repo in a graph depot. See hybrid workspace.
-
(No longer offered to new customers) A Perforce product that integrates Git with Helix Core Server. Replaced by the Git Connector component of Helix Core Server
-
A depot of type graph that is used to store Git repos managed by Helix Core Server. See also Git Connector and classic depot.
-
A feature of Helix Core Server that makes it easier to manage permissions for multiple users.
-
The list of file revisions currently in the client workspace.
-
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.
-
A process that allows one server to monitor another server, such as a standby server monitoring the master server. See the 'p4 heartbeat' command.
-
Enables an administrator to integrate Helix products with the organization's Identity Provider (IdP) to facilitate authentication through SAML or OIDC.
-
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.
-
A client-side agent that reduces the wait time when syncing from the server to a client workspace.
-
A web-based code review tool for Helix Core. Contributors share files, comment, suggest tasks, vote up or down, and submit final work.
-
A Perforce management platform for code and artifacts. Helix TeamHub offers built-in support for Git, SVN, Mercurial, Maven, and more.
-
A client workspace that supports both repos of type graph (see 'Git Connector') and the classic Helix Core 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.
-
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 metadata.
-
A special filespec that gives a meaningful name to a set of file revisions. A reference such as @Release2.3-August-2023 might be easier to remember than //depot/project/...@48296
-
The view that specifies which files in the depot can be stored with a particular label.
-
A method used by Helix Core 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 making additional copies of the file.
-
The librarian subsystem of the server stores, manages, and provides the archive files to other subsystems of the server.
-
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 syntax for file specifications that are specific to an 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.
-
Error output from the Helix Core Server. To specify a log file, set the P4LOG environment variable or use the p4d -L flag when starting the service.
-
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.
-
The innermost Helix Core server in a multi-server topology. A commit server can also be referred to as a master server.
-
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, such as P4Merge.
-
A file generated from two conflicting file revisions.
-
The data stored by Helix Core Server that describes the file revisions in the depot, where they get their content from (see lazy copy), and 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.
-
The time a file was last changed.
-
A completely empty revision of any file. For example, an empty file revision created by deleting a file or by syncing to the #none revision.
-
A pending changelist to which the server has assigned a number. This is distinct from the default of an unnumbered pending changelist.
-
The 'p4 obliterate' command permanently removes files and their history from the depot, unlike a deleted file, which can easily be recovered.
-
A copy of a Helix Core Server database that is kept up to date by manual or scripted processes that replay journals from a Helix Core 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 Helix Core Server.
-
The user who created a particular client, branch, or label.
-
The Helix Core Server command-line client program.
-
The program that runs Helix Core Server to manage depot files (versioned files) and the metadata of the server database.
-
The PHP interface to the Helix API, which enables you to write PHP code that interacts with a Helix Core Server machine.
-
A changelist that has not been submitted.
-
In Helix Swarm, a group of Helix Core 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.
-
The permissions stored in the Helix Core Server protections table. User permissions can be managed with the 'p4 protect' command and the P4Admin application.
-
A Helix Core server application that caches versioned files and is able to deliver them to clients on behalf of a Helix Core Server. Often deployed on remote sites where bandwidth to the Helix Core Server is limited and avoids multiple transfers of the same files from the Helix Core Server.
-
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. Helix Core Server uses RCS format to store text files. See also reverse delta storage.
-
A depot located on a different Helix Core Server that the current Helix Core Server can access.
-
A Helix Core Server that automatically maintains a full or partial copy of the master server's metadata and that might contain related file content. The replica copies from its master by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery.
-
A graph depot contains one or more repos, and each repo contains files that the Git Connector caches or mirrors from Git users.
-
The process you use to manage the differences between two revisions of a file, or two versions of a stream spec.
-
The method that Helix Core Server uses to store revisions of text files. The server stores the changes between each revision and its previous revision.
-
To discard changes you made to a file in your client workspace without submitting the changes to the depot.
-
A special protections level that includes read and list accesses, and grants permission to run the 'p4 review' command.
-
A program that periodically checks the Helix Core Server machine to determine if any changelists have been submitted. If so, the daemon sends an email message to users who have subscribed to watch any of the files included in those changelists.
-
A number indicating which revision of the file is being referred to. For example, myfile#5 designates the fifth revision, prefixed with the pound sign (#).
-
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.
-
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.
-
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.
-
The process of temporarily storing files in the server without checking in a changelist. Shelves are often used for reviews.
-
An entry within the db.storage table to track references to an archive file.
-
A branch with built-in rules that determine which changes to propagate to files in a stream depot, and in what order. A stream specification defines a stream. A user creates a stream spec by using 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.
-
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.
-
Defined by the Paths, Remapped, and Ignored fields of the stream specification. See Form Fields in the 'p4 stream' 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 Helix Core Server, including commands that set protections, install triggers, shut down the service for maintenance, as well as perform failover and failback.
-
A file type that Helix Core Server assigns to symbolic links. On platforms that do not support symbolic links with POSIX compliance, such as Windows, symlink files appear as small text files.
-
To copy file revisions from the depot to your client workspace.
-
The file that receives the changes from the donor file when you integrate changes between two codelines.
-
The file type that Helix Core Server assigns to files that contains only ASCII text, including Unicode text. See binary file type.
-
The revision in the depot with which the client file (yours) is merged when you resolve a file conflict. When you are working with branched files, theirs is the donor file.
-
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.
-
Data about the set of Helix Core services deployed in a multi-server installation, which might include commit-server, edge servers, standby servers, proxies, and brokers. P4Admin's Topology tab visualizes the topology and can export the details, which might help for troubleshooting.
-
A script you create to customize server behavior. Your trigger is automatically invoked when specific conditions are met. See the Helix Core Server Administrator Guide on 'Triggers'.
-
The 'p4 triggers' form in which each trigger is defined by four fields. Sometimes referred to as the 'triggers table'.
-
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.
-
The identifier that Helix Core 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.
-
A special character used to match other characters in strings. (1) * matches anything except a slash. (2) ... matches anything including slashes and is often used in views. (3) %%0 through %%9 is used for parameter substitution in views.
-
See client workspace.
-
An internal list indicates which files and revisions the client workspace has sync'd from the depot. See 'p4 have' in Helix Core Command-Line (P4) Reference.
-
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 protection level that enables you to run commands that alter the contents of files in the depot. Write access also includes the ability to read and list files.
-
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.
A
B
C
D
E
F
G
H
I
J
L
M
N
O
P
R
S
T
U
V
W
Y
