3.1. Work from the Point of View of a Single Developer

Using ComPact, every developer has one or more local workspaces. A local workspace is just a directory that contains one or more software packages in concrete versions on which the developer is currently working. All changes to software packages are made in local workspaces. The changes then are compiled and tested there, and finally -- if the developer is satisfied with the results -- written back to the central source code repository, and shipped -- in binary form -- to one or more package pools, which the developer and her/his colleagues use.

Have a look at figure Figure 3-1 for a first overwiew.

The source code repository is where the complete history of all changes to the sources of all the software packages is kept. Every single version of every package that has once been committed to the source code repository may immediately be reproduced via the unique name ComPact has created for it. You don't need to be afraid that all the versions of all the software you have written will take up a huge amount of disk space, since only the differences between two successing versions are actually stored, so that the growth of the repository is usually quite acceptable.

The source code repository is always accessed by the Elego ComPact tools via a special client/server protocol that is based on TCP. It may thus be located on a dedicated server machine (specially secured, fail-safe and backed up on a regular schedule).

Version control in Elego ComPact is based on a simple and easy-to-understand concept of checkin/checkout. A developer checks out the latest version from the repository, works on it, and checks in his changes to the repository to make them available to other developers. The actions for checkout are usually called checkout if it is the initial (first) checout of a package, and update if a local copy of the package already exists. The action of checking in the changes to the repository is also called commit.

For the purpose of compiling, linking, and testing her/his software, each developer has access to one or more package pools. Package pools contain the exported and derived elements of software packages that are needed if the package is used (imported) by another package (maybe from another developer). Package pools may be regarded as caches for the results of build runs, that speed up the building of large systems considerably.

The action of constructing all the derived elements of a package (e.g. object files, libraries, formatted and layouted documents) is called building. Elego ComPact contains a very sophisticated build system that may be used to compile and link C, C++, Java, Modula and many other program language source files, and format and layout SGML, TeX, LaTeX and virtually any format you want, as long as there is a usable command line interface to the tools that perform these actions.

The action of transferring a package from the local workspace to a package pool is called shipping, while the use of a package from a package pool is called import. Importing a package is done by simply writing an import statement in the package description file (PkgDesc).