next up previous
Next: Support for Cooperation Up: EPOS Previous: The task relation

Change Oriented Versioning (COV)


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 => Ambition
We present an ``incremental'' example in order to show the use of COV and its potential.
Let us imagine that a software system has been put under COV control. In order to facilitate portability, the software system has been architectured as follows (see 1.12):

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), (s)he just needs to check-out the module, operate the desired modifications and check it in again with an ambition which lets the architecture-related options unset.
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 dependent.
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.

next up previous
Next: Support for Cooperation Up: EPOS Previous: The task relation

Passani Luca
Mon Feb 20 21:59:27 MET 1995