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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,39e272d357c68416 X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Is Apex dead as an environment for Ada & Java? Date: 1999/11/30 Message-ID: <38441841.F28C96B1@hso.link.com> X-Deja-AN: 554944279 Content-Transfer-Encoding: 7bit References: <11f733ec.57d88b68@usw-ex0107-042.remarq.com> <384127A5.61431A14@dowie-cs.demon.co.uk> <0a0133f8.3baf10c0@usw-ex0101-001.remarq.com> <81s370$7am$1@nnrp1.deja.com> <0a0133f8.7900d89e@usw-ex0102-015.remarq.com> <3842C457.CBC87C2@hso.link.com> <20c2f050.4d65ccc7@usw-ex0101-003.remarq.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Scientific & Technical Services Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-11-30T00:00:00+00:00 List-Id: jim_snead wrote: > > In article <3842C457.CBC87C2@hso.link.com>, "Samuel T. Harris" > wrote: > > > > > I've used Apex since its inception and its R1000 predecessors > > for years before that. I have found from experience that subsystem > > design is more about the flow of work than about the organization > > of code. > > While the tips given by Jim Snead are valuable, the concerns > > they address are not my primary concerns when I'm allocation > > subsystems to support a project. The organization the teams > > is primary. How many developers are involved? How are the > > developers partitioned into teams? What manager layers > > are involved in inter-team coordination? What are the logistics > > involved in the scheduling of each team's releases? > > From the marketing claims this seems to be the job of Rational > Summit and not Apex. Historically, Summit has been only recently extracted from the original Apex tool. I really don't think of them as different tools most of the time since the integration of the development environment and the configuration management environment is so seemless. > > > As many have alluded to, Apex is overkill for a small project. > > Apex shines for huge projects. And once in place in an organization > > to support a single huge project, then it is already available > > for the small ones as well. > > I also believe that tools such as CVS may work for a huge project, > but I need more info to support this claim. Apparently there are > good graphical front ends to CVS, including emacs. Please note that Summit/CM uses RCS internally. It not the core which makes it feasible, but the wrapper. Summit/CM uses a vastly different approach from CVS yielding vastly different tool sets. Answering the kinds of questions above should provide valuable clues as to which tool set will be a better match. > > > I'd also like to add some technical attributes I've come to > > appreciate over the years. > > 1. The configuration management information resides in the > > subsystem. Each view uses it to generate its content. Since > > the subsystem and views can have different physical storage > > locations, I can spread by stuff around and limit my exposure > > to a disk crash. > > I believe other solutions to this include redundant disks, > nightly backups, etc. I think Apex wants you to also place > executables in subsystems. I typically place all object files > and images away from the source code. This would prevent > applications from mixing with source code. I agree that deliverables should be separate from the code. That is why my Ada mains are in different subsystems from the bulk of the code supporting the project. I can also use separate subystems for operational loads. In such an organization, a project subsystem produces Ada main executables. This subsystem, along with many other project subsystems provide all the necessary components for a load (data points, config files, etc.). The operational subsystem is responsible for gathering all these load build elements together into a single shrink-wrapped load area. This area is then used for delivery to the customer. Apex provides a healthy array of customization points to automate the process if one so chooses. > > Unix symbolic links are also useful for assigning code to > various mounted file systems. Apex does not preclude using symbolic links. Use then when they make sense. Indeed, I have had occasion to make artificial subsystems when the content of views were only symbolic links. Although not official supported, whenever I check-out one of these links, Apex has always traversed to the original subsystem for the CM functions. In this way, I am not limited to a single subsystem architecture but can support multiple organizational schemes to support different kinds of users. > > Overall I think (1) is a weak point. We have backups as well, but they take time to recover. If a disk crash takes out an entire subsystem and its views, then I have hundreds of developers who can't work while the disk is reconstructed from backups. Spreading the exposure keeps us going even while the crashed disk is replaced and reconstructed because most of my views are still around. This has paid dividends more than once in actually practice. > > > 2. Each subsystem is a self-contained configuration management > > area. I don't not have to be dependent on one single monolithic > > CM engine. This also limits my exposure to CM related problems. > > Either it is a single monolithic engine or you will have to > do the maintenance imports on lots of little monolothic > engines. For a large project, I would much rather do the > first. What is the expectation, that a monolithic version > controlled code base might break if you put too much code into it? > I have not seen evidence of this occurring. Using configuration files (lists of views) makes managing the growing complexity of imports a breeze. The problem with lots of little subsystems is the number of view imports required to hook everything together. In other words, a fine namespace involves lots of names. Using configuration files, many related views are managed as a single entity. This get me back to a coarse namespace with just a few names to be tracked. As to the monolithic engine breaking, we've seen this happen on more than one occasion due to disk crashes. I think it just makes sense to limit exposure by dividing content. With the advent of Clearcase integration into Apex and the availability of RAID storage, these considerations deserve another look. > > > 3. The clear separation between subsystems provides important > > configuration management controls and enforces a minimal level > > of discipline upon developers. I also like the use of histories > > instead of free-for-all branching supported by other tools. > > I can branch in Apex with histories, it just takes more work, > > and therefore more thought on just what exactly I need to do. > > As a parting thought, I do really miss that Ada command-line > > environment on the old R1000's. > > I don't think anyone would recommend free-for-all branching. > Here is the way to do it in CVS: > > CVSROOT > - history1 > - subdir1 > - subdir2 > - history2 > - subdir1 > - subdir2 > > Integration "view" which brings together different branches > - history1-subdir2 > - history2-subdir1 > > The key thing to remember is that histories or branches > are top-level entities that must be planned for, residing > close to the root of the hiearchy. The reason people > have problems with branching is that it cannot be an > afterthought. You'll get no argument from on on that! -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!"