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.
-
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).
-
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.
-
Helix Broker, a server process that intercepts commands to the Helix Core Server and is able to run scripts on the commands before sending them to the 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.
-
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 in a multi-server topology that includes edge servers. The commit server processes submitted files (changelists), global workspaces, and promoted shelves.
-
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 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).
-
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 conlict 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 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.
-
The component of Helix Core Server 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 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 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 specifying a filename that is specific to an operating system. This syntax is used as the second part of the client workspace mapping, after the depot syntax.
-
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. 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.
-
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 files in the depot, the current state of client workspaces, protections, users, labels, 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 manages depot files and metadata.
-
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 that stores versioned files. A proxy server does not run any commands. It serves versioned files to clients.
-
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 metadata and none, some, or all of the related file archives by copying data from a master Helix Core Server using 'p4 pull' or 'p4 journalcopy'.
-
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 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.
-
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
