From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c6567772e9f3871d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.27.230 with SMTP id w6mr25502454pbg.3.1318859573292; Mon, 17 Oct 2011 06:52:53 -0700 (PDT) Path: d5ni21904pbc.0!nntp.google.com!news1.google.com!postnews.google.com!g25g2000yqh.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: organizing deep source trees with child packages Date: Mon, 17 Oct 2011 06:37:26 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <21c9e6bb-f4f7-4a00-bde7-68f2c1a42d01@q13g2000vby.googlegroups.com> <82ty7d1ewz.fsf@stephe-leake.org> <3486b228-abdd-490f-b4ef-9ee6b19f65fa@gy7g2000vbb.googlegroups.com> <7179717a-9837-476c-b564-6599a9c02acd@ff5g2000vbb.googlegroups.com> <1qk4l4n9zsdgm$.1bvxdhoq5cpx5.dlg@40tude.net> <82hb39umkd.fsf@stephe-leake.org> <92b4070b-28d5-4e20-99a2-d3cc5c130510@s14g2000vbj.googlegroups.com> <87ipnon3qy.fsf@ludovic-brenta.org> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 X-Trace: posting.google.com 1318859573 12704 127.0.0.1 (17 Oct 2011 13:52:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 17 Oct 2011 13:52:53 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: g25g2000yqh.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-Via: ICAP/1.0 192.168.152.4 X-Google-Web-Client: true X-Google-Header-Order: HUALESRCVNK X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Red Hat/3.6-2.el5 Firefox/3.6.13,gzip(gfe) Xref: news1.google.com comp.lang.ada:18521 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-10-17T06:37:26-07:00 List-Id: Simon Wright wrote on comp.lang.ada: > Ludovic Brenta writes: >> No, the "subsystem" in Rational has nothing to do with visibility; it >> was only a configuration management entity. =A0You could declare that a >> subsystem A with version number N depended on a subsystem B with >> version number M. =A0There was no mechanism (that I remember) to hide >> part of a subsystem from the outside. =A0And TTBOMK the GNAT 'stand- >> alone library' is not about version control or configuration >> management, since it is not versioned. > > The paper at - 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: [...] =A0c. 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.