Turning to the technicalities of package version management with ComPact, the following items should be kept in mind throughout:
What to Put Under Version Control: As indicated above, it is actually the PkgDesc and the source files contained in a package that are to be put under version control. Extending everything to derived files is, obviously, not necessary, as these ones can always be recreated once some particular version is checked out. Such a practice would, also, be very un-efficient in terms of storage utilization.
Tags: In accordance with standard practice, concrete references to package versions do not merely consist of version numbers but, somewhat redundantly, of tags. The syntax is as follows:
devel_<package_name>_d<major_number>_<minor_number>_<patch_level>
head | headoftrunk | topoftrunk | head-of-trunk | top-of-trunk | top
headofbranch | tipofbranch | head-of-branch | tip-of-branch | tip
last-release-branch | lastreleasebranch | latest-release-branch |
latestreleasebranch | latest-tip | latesttip | last-tip | lasttip
release_<package_name>_<major_number>_<minor_number>_<patch_level>
release_<package_name>_<major_number>_<minor_number>_stable
Predictably, the first form is called a
development tag, and the third and fourth forms are
called release tags. The second form
is a development tag as well, since it refers to the head of
the main trunk. Also, the second and fourth forms are called
floating tags, while each tag that
does not refer to the head of the main trunk, or to the head
of some release branch, is called a
sticky tag. Terminology: For the sake of clarity, a work package is understood to be any actual package directory structure in ones work space. A work package is the current work package whenever the current working directory is the same as its root or one of its sub-directories.
Possible Relationships Between the Repository and a Work Package: A work package is always tagged with a reference to a unique package version. Then the predicates below are of interest whenever that tag is a floating tag. The reason why they are important has two parts: First, the package was up-to-date wrt. the head of the development trunk or the head of some release branch when it was put in place or, in other words, checked out; second, this situation may change because one or more new versions have been checked in from elsewhere. So there are the following possibilities:
There have not been any modifications in situ. Whether or not any newer version(s) have been checked in from elsewhere does not matter.
There have been modifications in situ and, at the same time, there has not been any check in of a newer version from elsewhere.
There have been modifications in situ and, at the same time, at least one newer version has been checked in from elsewhere.