Glossary
Term | Definition |
---|---|
access level |
A permission assigned to a user to control which Helix commands the user can execute. See protections. |
admin access |
An access level that gives the user permission to run Helix commands that override metadata but do not affect the state of the service. |
apple file type |
Helix file type assigned to files that are stored using AppleSingle format, permitting the data fork and resource fork to be stored as a single file. |
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. |
base |
The file revision on which two newer, conflicting file revisions are based. |
binary file type |
Helix file type assigned to a non-text file. By default, the contents of each revision are stored in full, and the file is stored in compressed format. |
branch |
(noun) A set of related files created by copying files, as opposed to adding files. A group of related files is often referred to as a codeline. (verb) To create a stream by copying another stream with |
branch form |
The Helix form you use to modify a branch. |
branch mapping |
Specifies how a branch is to be created by defining the location of the original codeline and the branch. The branch mapping is used by the integration process to create and update branches. Client workspaces, labels, and branch specifications cannot share the same name. |
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. See branch. |
changelist |
An atomic change transaction in Helix. The changes specified in the changelist are not stored in the depot until the changelist is submitted to the depot. |
changelist form |
The Helix form you use to modify a changelist. |
changelist number |
The unique numeric identifier of a changelist. |
change review |
The process of sending email to users who have registered their interest in changes made to specified files in the depot. |
checkpoint |
A copy of the underlying metadata at a particular moment in time. See metadata. |
classic depot |
The depot name that is assumed when no name is specified. The default depot
name is |
client form |
The Helix form you use to define a client workspace. |
client name |
A name that uniquely identifies the current client workspace. |
client root |
The root directory of a client workspace. If two or more client workspaces are located on one machine, they cannot share a 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. |
workspace view |
A set of mappings that specifies the correspondence between file locations in the depot and the client workspace. |
client workspace |
Directories on your machine where you work on file revisions that are
managed by Helix. By default this name is set to the name of the machine on
which your client workspace is located; to override the default name, set the
|
codeline |
A set of files that evolve collectively. One codeline can be branched from another, allowing each set of files to evolve separately. |
conflict |
One type of conflict occurs when two users open a file for edit. One user submits the file, after which the other user can’t submit because of a conflict. The cause of this type of conflict is two users opening the same file. The other type of conflict is when users try to merge one file into another. This type of conflict occurs when the comparison of two files to a common base yields different results, indicating that the files have been changed in different ways. In this case, the merge can’t be done automatically and must be done by hand. The type of conflict is caused by non-matching diffs. See file conflict. |
counter |
A numeric variable used by Helix to track changelist numbers in conjunction with the review feature. |
default changelist |
The changelist used by Helix commands, unless a numbered changelist is specified. A default pending changelist is created automatically when a file is opened for edit. |
default depot |
The depot name that is assumed when no name is specified. The default depot
name is |
deleted file |
In Helix, a file with its head revision marked as deleted. Older revisions of the file are still available. |
delta |
The differences between two files. |
depot |
A file repository hosted on the Helix server. It contains all versions of all files ever submitted to the depot. There can be multiple depots on a single installation. |
depot root |
The 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 |
Helix syntax for specifying the location of files in the depot. |
detached |
A machine that cannot connect to the Helix server. |
diff |
(noun) A set of lines that don’t match when two files are compared. A conflict is a pair of unequal diffs between each of two files and a common third file. (verb) To compare the contents of files or file revisions. |
donor file |
The file from which changes are taken when propagating changes from one file to another. |
exclusionary mapping |
A view mapping that excludes specific files. |
exclusionary access |
A permission that denies access to the specified files. |
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; typically occurs when another user opens the file for edit after you have opened the file for edit. |
file pattern |
Helix command line syntax that enables you to specify files using wildcards. |
file repository |
The master copy of all files; shared by all users. In Helix, 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, for example: |
file tree |
All the subdirectories and files under a given root directory. |
file type |
An attribute that determines how Helix stores and diffs a particular file.
Examples of file types are |
fix |
A job that has been linked to a changelist. |
form |
Screens displayed by certain Helix commands. For example, you use the Helix change form to enter comments about a particular changelist and to verify the affected files. |
full-file storage |
The method by which Helix stores revisions of binary files in the depot:
every file revision is stored in full. Contrast this with reverse delta
storage, which Helix uses for |
get |
An obsolete Helix term: replaced by sync. |
group |
A list of Helix users. |
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. |
integrate |
To compare two sets of files (for example, two codeline branches) and:
|
Inter-File Branching |
Helix’s branching mechanism. |
job |
A user-defined unit of work tracked by Helix. The job template determines what information is tracked. The template can be modified by the Helix system administrator. |
job specification |
A specification containing the fields and valid values stored for a Helix job. |
job view |
A syntax used for searching Helix jobs. |
journal |
A file containing a record of every change made to the Helix server’s metadata since the time of the last checkpoint. |
journaling |
The process of recording changes made to the Helix server’s metadata. |
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 Helix to make internal copies of files without duplicating file content in the depot. Lazy copies minimize the consumption of disk space by storing references to the original file instead of copies of the file. |
license file |
Ensures that the number of Helix 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 Helix server. |
local syntax |
The operating-system-specific syntax for specifying a filename. |
lock |
A Helix file lock prevents other clients from submitting the locked file.
Files are unlocked with the |
log |
Error output from the Helix server. By default, error output is written to
standard error. To specify a log file, set the |
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. The left side specifies the depot files, and the right side specifies the client files. (See also workspace view, branch view, label view). |
MD5 checksum |
The method used by Helix to verify the integrity of archived files. |
merge |
To create new files from existing files, preserving their ancestry (branching), or to propagate changes from one set of files to another. Also, the process of combining the contents of two conflicting file revisions into a single file, typically using a merge tool like P4Merge. |
merge file |
A file generated by Helix from two conflicting file revisions. |
metadata |
The data stored by the Helix server that describes the files in the depot, the current state of client workspaces, protections, users, labels, and branches. Metadata includes all the data stored in the service except for the actual contents of the files. |
modification time |
The time a file was last changed. |
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 |
numbered changelist |
A pending changelist to which Helix has assigned a number. |
open file |
A file that you are changing in your client workspace. |
owner |
The Helix user who created a particular client, branch, or label. |
|
The Helix Command Line program, and the command you issue to execute Helix commands from the operating system command line. |
|
The program that runs the Helix server; |
P4Diff |
A Helix application that displays the differences between two files. P4Diff is the default application used to compare files during the file resolution process. |
pending changelist |
A changelist that has not been submitted. |
Helix server |
The Helix depot and metadata; also, the program that manages the depot and metadata. |
protections |
The permissions stored in the Helix server’s protections table. |
RCS format |
Revision Control System format. Used for storing revisions of text files. RCS format uses reverse delta encoding for file storage. Helix 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 Helix. |
remote depot |
A depot located on on a host other than that hosting the currently-specified Helix server. |
reresolve |
The process of resolving a file after the file is resolved and before it is submitted. |
resolve |
The process you use to reconcile the differences between two revisions of a file. You can choose to resolve conflicts by selecting a file to be submitted or by merging the contents of conflicting files. |
resource fork |
One fork of a Mac file. (These files are composed of a resource fork and a
data fork.) You can store resource forks in Helix depots as part of an
AppleSingle file by using Helix’s |
reverse delta storage |
The method that Helix uses to store revisions of text files. Helix 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. |
review access |
A special protections level that includes |
review daemon |
Any daemon process that uses the |
revision number |
A number indicating which revision of the file is being referred to. |
revision range |
A range of revision numbers for a specified file, specified as the low and
high end of the range. For example, |
revision specification |
A suffix to a filename that specifies a particular revision of that file. Revision specifiers can be revision numbers, change numbers, label names, date/time specifications, or client names. |
service |
In Helix, the shared versioning service that responds to requests from
Helix applications. The Helix server ( |
server root |
The directory in which |
shelving |
The process of temporarily storing files in the Helix 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. |
stream |
A stream is a branch, but with additional intelligence that determines what changes can be made and in what order they must be made. |
submit |
To send a pending changelist and changed files to the Helix server for processing. |
subscribe |
To register to receive email whenever changelists that affect particular files are submitted. |
super access |
An access level that gives the user permission to run every Helix command, including commands that set protections, install triggers, or shut down the service for maintenance. |
symlink file type |
A Helix 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 depot to a client workspace. |
target file |
The file that receives the changes from the donor file when you are integrating changes between a branched codeline and the original codeline. |
text file type |
Helix file type assigned to a file that contains only ASCII text. See also binary file type. |
theirs |
The revision in the depot with which the client 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. |
tip revision |
In Helix, the head revision. Tip revision is a term used by some other versioning systems. |
trigger |
A script automatically invoked by the Helix server when changelists are submitted. |
two-way merge |
The process of combining two file revisions. In a two-way merge, you can see differences between the files but cannot see conflicts. |
typemap |
A Helix table in which you assign Helix file types to files. |
user |
The identifier that Helix uses to determine who is performing an operation. |
view |
A description of the relationship between two sets of files. See workspace view, label view, branch view. |
wildcard |
A special character used to match other characters in strings. Helix wildcards are:
|
workspace |
See client workspace. |
write access |
A protection level that enables you to run commands that alter the contents of
files in the depot. |
yours |
The edited version of a file in the client workspace when you resolve a file. Also, the target file when you integrate a branched file. |