One of the classical issues of SCM, i.e. version selection, is mastered with a totally different approach in EPOS. Traditional versioning systems [Tic88] manage every object under their control by maintaining a ``version graph'' of it, like the one in figure 1.11. In practice, there exists a set of (logically) distinct objects, representing the ``evolution'' of a certain component :
Figure 1.11: Traditional versioning of an object.
Such approach presents a few problem:
In COV [Hol88] [L+89] [MLG+93],
a version is not an explicit object, but the result of
certain changes that have been applied to the DataBase.
Not all the changes are included in the chosen version, but only
a combination of
those specified by the values of user-definable options.
Options are boolean logical values which determine the view of the database the user wants to work on. For instance, the user might be interested in having a look at the software system released for the UNIX operating system, even though versions for different operating systems are stored in the database. Asking for a view which respects the ``UNIX= true'' constraint, for example, will yield the desired configuration.
Two sets of options must be specified when starting a transaction which interacts with the EPOSDB:
Obviously, in order to let the user see what (s)he is doing, the choice-dependent version being modified must be part of all the impacted Ambition-dependent version. If we regard Choice and Ambition as two logical predicates, this could be formally stated as:
Choice => AmbitionWe present an ``incremental'' example in order to show the use of COV and its potential.
Figure 1.12: A small platform-dependent software system
As already said, extracting a configuration of the software system
suitable for any platform is straightforward. But let us consider
the following small scenario for a more significant example.
If the user wants to change the
implementation of the linked list (from one which utilizes a
vector to a pointer-based one for reasons of efficency, for instance),
needs to check-out the module, operate the desired modifications and
check it in again with an ambition which lets the architecture-related
All of the platform-related versions will be, thus, uniformly and transparently modified.
Of course, such a modification in a suitably structured system like this would not pose many problems for any versioning system. The potential of COV can be seen in the following case: let us immagine that the basic machine-independent algorithm has been modified by three different teams (which acceded the database with the same choices, but different ambitions) in order to produce three machine dependent specializations of the system (see 1.13).
Figure 1.13: Three variants of the same system
The three variants produced are managed by COV. Each module contains
the code of the original module (the one implementing the linked list,
for example) intermixed with the code which makes it architecture
If the implementation of the linked list is changed (exactly as in the previous example) and a platform-dependent version which takes the change into account is checked out (i.e. by the Choice: <List-Enhanc=True,Xlib=True>), the user obtains the enhanced version for the platform (even though no one-to-one relation is present between this version and any object in the database).
Actually, such a module is only theoretically consistent, in that there might be a few discrepancies which will not let it (for example) compile properly, nevertheless the application of a supposedly small set of fixes will adjust everything. If such fixes are applied with an <List-Enhanc=True,Xlib=True> Ambition, the configuration will be ``frozen'' and the above merge will be quite trasparent to the COV user.