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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: jim_snead Subject: Re: Is Apex dead as an environment for Ada & Java? Date: 1999/11/29 Message-ID: <20c2f050.4d65ccc7@usw-ex0101-003.remarq.com>#1/1 X-Deja-AN: 554684641 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> X-Originating-Host: 207.58.17.233 X-Complaints-To: wrenabuse@remarq.com X-Trace: WReNphoon3 943929850 10.0.2.3 (Mon, 29 Nov 1999 18:44:10 PST) Organization: http://www.remarq.com: The World's Usenet/Discussions Start Here NNTP-Posting-Date: Mon, 29 Nov 1999 18:44:10 PST Newsgroups: comp.lang.ada X-Wren-Trace: eOzJ4eD5vvS/rvn3+rvi6vrf8fCk7Knw6K7g4Oi4p/y0pPm1rP2urLK+uw== Date: 1999-11-29T00:00:00+00:00 List-Id: 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. > 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. > 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. Unix symbolic links are also useful for assigning code to various mounted file systems. Overall I think (1) is a weak point. > 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. > 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. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free!