regexps.com
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.
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.
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
regexps.com