earlw@Apple.COM (Earl Wallace) (12/08/88)
I'm looking for final solution in maintaining UNIX source code. I know about SCCS, RCS, Make and NewMake, but I was wondering if there is something out there that goes beyond these programs. Maybe a database-driven software maintenance system that keeps all module information in the database and allows you to build any release of your UNIX software at anytime. I have an open mind and if anyone has any knowledge of any product, at any cost (including free or Public-Domain) that can do a better job of maintaining UNIX source code than the UNIX programs mentioned above, please send your information to me and I summarize it for everyone. Earl Wallace AppleLink: EARL.WALLACE Internet: earlw@apple.com Phone: (408) 974-4691
rterek@pitstop.UUCP (Robert Terek) (12/09/88)
In article <21896@apple.Apple.COM> earlw@apple.com (Earl Wallace) writes: >I'm looking for final solution in maintaining UNIX source code. I know about >SCCS, RCS, Make and NewMake, but I was wondering if there is something out >there that goes beyond these programs. Maybe a database-driven software >maintenance system that keeps all module information in the database >and allows you to build any release of your UNIX software at anytime. I've often wondered about this, especially after using Apollo Computer's DSEE system (Domain Software Engineering Environment). DSEE is much more sophisticated than make/sccs (build according to a "thread", distributed building, etc.), it's too bad it only runs under AEGIS. Does anyone know if Apollo plans to port DSEE to UNIX? Has anyone else designed a software maintenance tool that approaches DSEE in functionality, but runs under UNIX? Bob Terek Contractor, Sun Microsystems rterek@sun.com
gnu@hoptoad.uucp (John Gilmore) (12/12/88)
Sun sells a product called "NSE" which was designed to solve this kind
of "programming in the large" problem. I think the SunOS 4.0 release
was not built with it (not quite ready/stable yet) but the upcoming
4.1 is being built with it (though I could be wrong).
I thought I remembered a Usenix paper about it, but I've looked through
1986-88 and didn't find it. Can someone from Sun who knows about this
post a summary of it? My impression was that it was a neat system that
has never received the emphasis or publicity that it deserves.
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
"The network *is* the confuser."pcg@aber-cs.UUCP (Piercarlo Grandi) (12/12/88)
In article <21896@apple.Apple.COM> earlw@apple.com (Earl Wallace) writes:
I'm looking for final solution in maintaining UNIX source code. I know
about SCCS, RCS, Make and NewMake, but I was wondering if there is
something out there that goes beyond these programs.
On some BSD contrib tape you can find SPMS. I does maintain, for each
directory, an index to things, and can link together makefiles, rcs/sccs files,
in several distinct directories, organized in projects/subprojects, quite
smoothly. I use it to maintain the Ingres source, which is even larger than
that for Unix and the basic commands.
SPMS has a few defects, it is tedious and somewhat inflexible (it insists
that you have a distinct directory for each executable/library you want to
build), but overall it is quite nice and commendable. It hasn't caught on
very much, probably because of a lack of sensibility to issues of big
projects in the Unix world>
Maybe a database-driven software maintenance system that keeps all module
information in the database and allows you to build any release of your
UNIX software at anytime.
Here I can only observe that if you want an IPSE, you had better consider
carefully which one you want. Get some information, compare them, try them
out before committing to a specific one.
--
Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)daveb@gonzo.UUCP (Dave Brower) (12/14/88)
In article <6042@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >Sun sells a product called "NSE" which was designed to solve this kind >of "programming in the large" problem. I think the SunOS 4.0 release >was not built with it (not quite ready/stable yet) but the upcoming >4.1 is being built with it (though I could be wrong). > >I thought I remembered a Usenix paper about it, but I've looked through >1986-88 and didn't find it. Can someone from Sun who knows about this >post a summary of it? My impression was that it was a neat system that >has never received the emphasis or publicity that it deserves. Both Sun's NSE and Apollo's DSEE look like perfectly wonderful products, suffers the same fatal flaw to different degrees. Both are proprietary solutions that aren't of much practical interest to people doing heterogenous development. Flexibility and hardware independance are the driving forces within the UNIX community. Therefore, it is more than a little problem in getting a large organization, which would benefit most from the methodology, to adopt a product that only runs on one brand of box. Perhaps when NSE is running on top of OpenLook, and licensed for use on other hardware... but I won't hold my breath. The market is really waiting for a third party equivalent that will run on a range of machines, supporting one of the emerging windowing standards. Is anybody working on this? -dB -- If life was like the movies, the music would match the picture. {sun,mtxinu,hoptoad}!rtech!gonzo!daveb daveb@gonzo.uucp
axel@coma.UUCP (Axel Mahler) (12/15/88)
In article <21896@apple.Apple.COM> earlw@apple.com (Earl Wallace) writes: >I'm looking for final solution in maintaining UNIX source code. I know about >SCCS, RCS, Make and NewMake, but I was wondering if there is something out >there that goes beyond these programs. Maybe a database-driven software >maintenance system that keeps all module information in the database >and allows you to build any release of your UNIX software at anytime. > We won't claim that this is the 'final solution', but what you're looking for sounds pretty much like "shape", a toolkit that we've just implemented. The toolkit consists of a set of version control commands and "shape", a significantly enhanced Make-oid. "shape" and the version control commands are integrated on top of AFS ("Attributed File System"), a dedicated version object base. The system features RCS-style version control and a configuration identification and -build process that has full access to all revisions in the object base (other than make which only knows about plain files). AFS also supports derived object management, i.e. it maintains a cache of multiple versions of compiled object-files (e.g. compiled c-files with different compile switches). The "shape" program itself is upward compatible to Make in that it can properly handle conventional Makefiles. The *Shapefile* however, uses Makefile-style dependencies as (versionless) 'abstract system model' and employs 'configuration selection rules' to dynamically bind particular version objects in the object base to the names listed in the system model. The version selection mechanism exploits AFS' ability to maintain any number of arbitrary attributes for objects in the object base. This yields a configuration identification mechanism similar to (but more flexible than) DSEE's 'configuration threads'. On special request, shape records an identified configuration in a 'configuration identification document' (CID) which has the form of a completely bound Shapefile (all object-instances are explicit). This makes it particularly easy to rebuild recorded configurations. As CID's are themselves documents, they can be placed under version control, making it easy to maintain histories of entire software systems. One of the most useful features of shape is its support of various variant administration techniques. Shape makes no assumptions about the semantics of the 'variant' notion other than having "alternative (conceptually equivalent) instances of the same concept" (e.g. 'module'). Despite the particular semantics of a certain variant-concept, there is a small number of techniques to physically handle variants. These techniques are what shape supports. Most commonly used techniques are: - equally named files in different directories - one source file representing multiple variants that are extracted by a preprocessor using different preprocessor switches (e.g. conditional compilation) - one source file processed by different tools or different tool versions/variants (e.g. cross compilation, different coders) - combinations of the above. Shape includes a variant definition facility that allows very flexible and convenient handling of all of the above variant administration techniques. The object base abstraction presented by AFS provides uniform access to immutable revisions of data entities ('files') stored in special archives, and mutable regular UNIX files. Consequently, the AFS based toolkit lives peacefully (and meaningfully!) together with standard filesystem applications (editors, compilers, formatters etc.). Cooperative work within projects is supported by a build-in status model, controlling visibility of version objects, and locking, a primitive form of 'long transactions'. The general concept of object attributes provides for passing information between indiviual tools that would otherwise be lost. This mechanism is useful for building integrated environments from a set of unrelated tools. The toolkit character of the system allows to use it via shell-commands, or to build a customized environment on top of it. As an example, we used GNU-Emacs as an alternate user interface to the system which lead to a much more comprehensive, integrated user interface. For more sophisticated requirements, there is a complete C-language interface to AFS, on top of which all the toolkit programs are built. There are - of course - some drawbacks that appear worth mentioning. First of all, the shape toolkit implementation has prototype character. Although all of the described functionality is operational, we don't have any experience with larger scale software development projects. The system may still contain serious bugs. Second, shape is not exactly blindingly fast. It kind of hurts to use it on a MicroVAX II (our development system), especially when an average of 10 people are logged in. People who have a 68020 class workstation on their desk will probably have fun with shape. Some important aspects, such as distributed builds (as addressed by DSEE), are not present in shape. A word concerning the status of the system. The shape toolkit is in beta test at a number of companies right now. It is, however, not clear to what degree shape is used on large scale software development efforts (version control and configuration management are long term critical issues for a software company, so there is understandable reluctance to commit oneself to an unproven tool system). Shape is not a 'product'. You can't buy it, and if you have it, there is no guaranteed support. The good news is: shape is free. We consider posting the whole matter to comp.sources.unix, or donating it to the GNU project (if they want it). The software is UNIX portable, i.e. it runs under 4.[23]BSD, SunOS 4.0, Ultrix 2.0+, and will run under System V.3 very soon. In case you find shape interesting, you may want to read "An Integrated Toolkit for Engineering Software Configurations", in "Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments", Nov. 1988, Boston Mass., or write to shape@coma.uucp which is the same as shape@db0tui62.bitnet. cheers, Axel. ------------- -- Axel Mahler, Tech.Univ. Berlin UUCP: axel@coma.uucp (unido!coma!axel) BITNET: axel@db0tui62.bitnet