The Hackerlab at regexps.com

Glossary

up: arch Meets hello-world
next: The GNU Free Documentation License
prev: Customizing the inventory Naming Conventions

archive - An archive is a repository of one or more projects. An archive can be located and accessed anywhere. A user may have an archive in his home directory or could keep his archive on a remote machine and access it via sftp. A project may choose to give public access to its archives via http, WebDAV and ftp.

arch - To reference an arch tree correctly, several pieces are needed: stanza the archive name, the archive location and possibly the category, branch, version and revision. This information is often passed from one to another in the unofficial form of an arch stanza. An arch stanza will often look like this:

                 someone@somewhere.com--2003
                 http://arch.somewhere.com/{archives}/2003
                 widget--devo--2.5--patch-96

arch stanza branch - A branch is an path of development for a category. Though projects must (and some simpler projects do) have at least one branch, larger projects will often have two or more branches for each category. For example a large project may have two branches in a category: mainline and devo . The mainline branch would carry development for the stable series while the devo branch would keep experimental work.

branched - A simple version in which the base-0 revision is a version continuation revision.

category - An archive is broken down into categories. Though subtle differences exist, for many a category is synonymous with the project itself. As an example, a developer may work on several different projects at the same time. Each project would be given a different category. A category in arch is what other revision control systems, such as cvs, call a repository.

category, - A fully qualified category is the combination of an archive fully name and category name in the format of qualified jdoe@example.com--example/mycategory

changeset - A changeset is collection of changes that change a software package from one revision to another

changeset - A revision created by 'commit' revision

commit - After changes are made to a tree, arch needs to be told that changes have occured and need to be recorded. This process, in slang terms, is called commiting changes to a branch

import - A revision created by the 'import' command. revision

log - A log is a detailed accounting of what changes have taken place between revisions in a software project.

pristine - A pristine tree is an copy of a project tree that has already copy been stored in the project archive to a copy of already stored within a project repository

ordinary - A version in which all but the base-0 revision are changeset version revision

package - A fully-qualified and unqualified names of categories, branches, name version and revisions

name project - A project has two meanings. In the more general form, a project is a gathering of developers and resources that have comitted to solving some sort of problem. In a stricter sense, especially within the realm of arch, a project refers to the collection of software that has been designed by the team that has gathered together to to solve a problem.

revision - A revision is generally a set of changes within a branch. As such, a revision is a product of the comitting process. Each time a developer commits a change to a tree a revision is created.

revision, - SEE: changeset revision changeset

revision, - SEE: import revision import

sealed - A version in which a 'version-0' revision exists version

stanza, - See arch stanza arch

version - Each branch in tla has one or more versions. The version is used to denote the major versions of the software. As an example, a hypothetical widget project may have both a 2 .4 and a 2 .4 series that are developed side by side.

version, - SEE: ordinary version

version, - SEE: ordinary version simple

version, - SEE: sealed version sealed

version - [ Definition needed here] tag

version - branched.

Concept Glossary

Branch/Category/Version/Revision examples

For this example imagine that there is a widget project that has even/odd releases. For example, 1 .2, 2 .4 and 3 .6 would all contain stable releases of software. Versions such as 1 .3, 2 .1 and 2 .5 would be a development series of the software. We could map our categories, branches, versions and revisions as such:

widget--mainline--2.4--patch-12 - This is widget 2 .4 with 12 patches. This tree is intended for people that wish to track official releases. widget--mainline--2.5--patch-5 - This is widget-2.4 with 5 patches applied. This tree is intended for those that wish to track official releases of 2 .5 widget--devo--2.4--patch-14 - This is the development tree of widget. 14 patches has been applied. This archive is intended for devolopers that work on the stable version of widget. widget--devo--2.5--patch-39 - This is the development tree of the 2 .5 development series of widget. This tree is intended for developers (and truly brave users) that wish to be on the cutting edge of widget.

Arch naming conventions

Given a name of the form: cat--branch--version--revision

        cat             is a "category name"
        branch          is a "branch label"
        version         is a "version id"
        revision        is a "patch level"

        cat                             is the name of a "category"
        cat--branch                     is the name of a "branch"
        cat--branch--version            is the name of a "version"
        cat--branch--version--rev       is the name of a "revision"

If arch is an archive, name, then:

        arch/cat                        is the "fully qualified" name
                                        of a category

        arch/cat--branch                is the "fully qualified" name
                                        of a branch

        and so forth.

arch Meets hello-world: A Tutorial Introduction to The arch Revision Control System
The Hackerlab at regexps.com