Helix Search Documentation | 2025.1

# 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 Helix Core Command-Line (P4) Reference.
- admin access
  An access level that gives the user permission to privileged commands.
- archive depot
  A special depot into which versioned files (also known as archive files) can be transferred.
- archive files
  Versioned files that users have submitted to a depot.
- atomic change transaction
  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.
- avatar
  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.
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.
- 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 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.
- 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 Helix Core component that is able to apply rules and scripts based on incoming commands before passing them to a designated Helix Core 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
  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.
- changelist form
  The form that appears when you modify a changelist with 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 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 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.
- 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 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 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.
- client syntax
  The syntax for specifying the location of files in the client workspace as opposed to the depot. Client syntax begins with //workspaceName/
- client workspace
  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.
- code review
  A process in 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. This allowing each set of files to evolve separately.
- comment
  Feedback provided in Helix Swarm on a changelist, review, job, or a file within a changelist or review.
- commit server
  The innermost Helix Core Server in a multi-server topology that implements the protocols required by 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. 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 best practice is to copy (and not merge) changes from less stable codelines to more stable codelines. 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 Helix Core 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. Older revisions of the file are still available. See also 'head revision' and 'obliterate'.
- delta
  The differences between two files.
- depot
  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.
- 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 depot as opposed to the client workspace. Depot syntax begins with //depotName/
- 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 conflict.
- distribution server
  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.
E
- edge server
  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.
- 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 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 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 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.
- 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 (#) and testfile#3 would be an example.
- 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 tree
  All the subdirectories and files under a given root directory.
- file type
  An attribute that determines how the server stores and diffs a particular file. Examples of file types are text and binary.
- form
  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.
- forwarding replica
  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.
G
- Git Connector
  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.
- graph depot
  A depot of type graph that is used to store Git repos managed by Helix Core Server. See also Git Connector and classic depot.
- group
  A feature of Helix Core 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.
- Helix Authentication Service (HAS)
  Enables an administrator to integrate Helix products with the organization's Identity Provider (IdP) to facilitate authentication through SAML or OIDC.
- Helix Core 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.
- Helix Core Virtual File Service (P4VFS)
  A client-side agent that reduces the wait time when syncing from the server to a client workspace.
- Helix Swarm
  A web-based code review tool for Helix Core. Contributors share files, comment, suggest tasks, vote up or down, and submit final work.
- Helix TeamHub
  A Perforce management platform for code and artifacts. Helix TeamHub offers built-in support for Git, SVN, Mercurial, Maven, and more.
- hybrid workspace
  A client workspace that supports both repos of type graph (see 'Git Connector') and the classic Helix Core 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 metadata.
L
- label
  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
- label view
  The view that specifies which files in the depot can be stored with a particular label.
- lazy copy
  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.
- librarian
  The librarian subsystem of the server stores, manages, and provides the archive files to other subsystems of the server.
- 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 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
- 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
  Helix Core Server supports human-readable logs as well as structured logs in a comma-separated value (CSV) format. The human-readable P4LOG environment variable specifies the log file for errors. The human-readable P4AUDIT environment variable specifies the log file that records file transfers to users. Structured log files are for many purposes. To learn more, see 'Logging" in Helix Core 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.
- master server
  The innermost Helix Core server in a multi-server topology. A commit server can also be referred to as a master server.
- 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, such as P4Merge.
- merge file
  A file generated from two conflicting file revisions.
- metadata
  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.
- modification time or modtime
  The time a file was last changed.
N
- nonexistent revision
  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.
- numbered changelist
  A pending changelist to which the server has assigned a number. This is distinct from the default of an unnumbered pending changelist.
O
- obliterate
  The 'p4 obliterate' command permanently removes files and their history from the depot, unlike a deleted file, which can easily be recovered.
- offline database
  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.
- 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 Helix Core Server.
- owner
  The user who created a particular client, branch, or label.
P
- p4
  The Helix Core Server command-line client program.
- p4d
  The program that runs Helix Core Server to manage depot files (versioned files) and the metadata of the server database.
- P4PHP
  The PHP interface to the Helix API, which enables you to write PHP code that interacts with a Helix Core Server machine.
- pending changelist
  A changelist that has not been submitted.
- project
  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.
- protections
  The permissions stored in the Helix Core Server protections table. User permissions can be managed with the 'p4 protect' command and the P4Admin application.
- proxy server
  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.
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. Helix Core Server uses RCS format to store text files. See also reverse delta storage.
- remote depot
  A depot located on a different Helix Core Server that the current Helix Core Server can access.
- replica
  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.
- repo
  A graph depot contains one or more repos, and each repo contains files that the Git Connector caches or mirrors from Git users.
- resolve
  The process you use to manage the differences between two revisions of a file, or two versions of a stream spec.
- reverse delta storage
  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.
- revert
  To discard changes you made to a file in your client workspace without submitting the changes to the depot.
- 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 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.
- revision number
  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 (#).
- 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.
S
- 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.
- shelve
  The process of temporarily storing files in the server without checking in a changelist. Shelves are often used for reviews.
- 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 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.
- 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
  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 from the client workspace to the depot.
- super access
  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.
- symlink file type
  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.
- sync
  To copy file revisions from the depot to your 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
  The file type that Helix Core Server assigns to files that contains only ASCII text, including Unicode text. See binary file type.
- theirs
  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.
- 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
  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.
- trigger
  A script you create to customize server behavior. Your trigger is automatically invoked when specific conditions are met. See the Helix Core Server Administration Documentation on 'Triggers'.
- triggers form
  The 'p4 triggers' form in which each trigger is defined by four fields. Sometimes referred to as the 'triggers table'.
- 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.
- user
  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.
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
- wildcard
  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.
- workspace
  See client workspace.
- workspace have list
  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.
- 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.
- write access
  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.
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