Manpage logo

bk-terms - (unknown subject)


NAME
bk terms − definitions of BitKeeper terms

DESCRIPTION
BitKeeper definitions:
package

This term is used when a distinction needs to be drawn between two different repositories which do not contain the same data, i.e. one contains a compiler and the other contains a debugger. To distinguish between them, refer to the compiler package or the debugger package. One way to think about it is that a package is a logical concept, somewhat like an object, while a repository is an instance of that object. Another way that people sometimes distinguish between packages is to talk about them having different root keys (each package has an internal identifier called the root key).

repository

A repository (also known as a work space, a clone, or an instance of a package) is where you do your work. A repository is an instance of a package i.e. there is one package, but there can be many instances of that package. Unlike other systems, such as CVS, every user gets their own repository, complete with revision history.

sfile

A file containing the revision history, e.g., SCCS/s.foo.c.

gfile

A file that is checked out, e.g., foo.c.

tag, symbol

A symbolic name (or tag) which is given to a particular revision of one or more files. e.g., “Alpha1”.

delta

A delta (also known as a revision or version) is a specific version of a file, or one change to a file, depending on context. When we mean the specific version of a file, we are talking about the entire file as of that version. When we mean the changes made in a specific delta, we are talking about the differences contained in that delta.

rev argument

Many commands take file revision numbers as arguments, usually to the −r option. On the command line anytime a revision number is expected, the delta key can be used instead. Or after an @ sign, a changeset revision, tag, or changeset key can be used. So [email protected] finds the version number as of changeset revision 1.4. So the following are all legal:

-r1.23
-r3dcc5f35PWiRWg8wiP7Dehy51Pk7DA
-r’[email protected]|man/man1/bk-terms.1|20020714011327|59990’
[email protected]
[email protected]
-r@’[email protected]|ChangeSet|20020912140445|17593’

ChangeSet

The file used to record the repositories’ history of changes.

cset, changeset

A particular change to a repository consisting of one or more changes to one or more files.

changeset number

Revision number for a changeset. These numbers fluctuate, but stabilize, over time. If you want an immutable, unique reference for a changeset, use the changeset key.

key A unique, unchanging identifier for a version of a file which may be used anywhere a normal revision number and/or symbolic tag is used. A particular key may be extracted with the following, the first form produces a longer key which is human readable, the second form produces a shorter key which is not human readable.

bk -R log -hr<rev> -nd:KEY: ChangeSet
bk -R log -hr<rev> -nd:MD5KEY: ChangeSet

package identity

Each BitKeeper package has a unique identity. All instances (repositories) of the package have the same package identity.

repository identity

Each repository has a unique identifier which is different across all repositories, regardless of the package.

pending

Deltas which have been checked into a file but not yet committed to a changeset.

patch

Formally, this is one or more changesets wrapped up for transmission to someone else. It is similar to what you may be used to thinking of as a patch (a list of all the changes between two versions of an entire package) but carries more information: who made the changes, when, and why.

Trunk

Main line source base. In BitKeeper revtool, the trunk is the X.Y in the graph, branches are X.Y.Q.Z, which always get merged into the trunk.

Tip, Top of Trunk (TOT)

The latest revision on the trunk.

graph difference

The graph difference between revision B and revision A (represented by the notation A..B) is the set of changes in B’s history that are not in A’s history.

/----> 1.1.1.1 ----> 1.1.1.2 -----\
/ \
/ \
1.1 ----> 1.2 ----------------------------> 1.3 ----> 1.4
\ /
\ /
\-----------> 1.1.2.1 ------------------------/

For example, in the graph above, 1.2..1.4 represents the list 1.1.1.1, 1.1.1.2, 1.1.2.1, 1.3, 1.4; 1.1.2.1..1.1.1.2 means 1.1.1.1, 1.1.1.2; and 1.1.1.2..1.1.2.1 consists only of 1.1.2.1.

NOTES
We attempt to list all of the BitKeeper definitions here, but send us a message at [email protected] if you have suggestions for definitions we may have missed.

CATEGORY
Overview


Updated 2026-06-01 - jenkler.se | uex.se