Re: organizing deep source trees with child packages

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Simon Wright wrote on comp.lang.ada:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>> No, the "subsystem" in Rational has nothing to do with visibility; it
>> was only a configuration management entity.  You could declare that a
>> subsystem A with version number N depended on a subsystem B with
>> version number M.  There was no mechanism (that I remember) to hide
>> part of a subsystem from the outside.  And TTBOMK the GNAT 'stand-
>> alone library' is not about version control or configuration
>> management, since it is not versioned.
>
> The paper at <http://dodreports.com/pdf/ada323647.pdf> - which is a
> PDF'd scan - doesn't seem to agree with this;
>
> on page 20, "The main reason for decomposing a system into subsystems is
> to control and manage complexity."
>
> on page 22, "a view [of a subsystem] manages: [...]  c. The visibility
> to program units in other subsystems."
>
> And the VCS - on the R1000 - was CMVC. I think that later versions of
> APEX use ClearCase?

I was talking about a version of APEX that included yet another
version control system, based on RCS and subsystems, and that tried to
mimick the VCS on the R1000.  This version of APEX could also use
ClearCase but that was an optional and expensive extra.  I don't know
what happened to APEX after these old versions; it is possible that
the "default" VCS was replaced with ClearCase.

About visibility: if you declared that subsystem A depended on
subsystem B, then all the units in A could see all the units in B.
There was no notion of private subsystems, or of private units within
a subsystem.  I think the units of B could also see the units of A;
this allowed a package spec to be in A and several possible bodies to
be in different versions of B or in different subsystems altogether.
But my memory is fuzzy on this point.

Anyway, as I said, this version control system was really bad at
merging.

--
Ludovic Brenta.