Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg From: pcg@aber-cs.UUCP (Piercarlo Grandi) Newsgroups: comp.software-eng Subject: Re: Source Code Control Message-ID: <1052@aber-cs.UUCP> Date: 5 Jul 89 17:14:16 GMT Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi) Organization: Dept of CS, UCW Aberystwyth (Disclaimer: my statements are purely personal) Lines: 81 In article geoff@tom.harvard.edu (Geoff Clemm) writes: When the database systems are as stable, inexpensive, and generally available as RCS and SCCS, the discussions will focus on them instead. You have a somewhat optimistic idea of what a DBMS is... RCS and SCCS are "database systems"? Since when? (I know that an argument can be made that the unix filesystem itself is a database system for files, but that is stretching definitions more than a bit...). And what about University Ingres, as "stable, inexpensive, and generally available"? Very few sw eng people do _not_ realize that database research is important for improving version control support, And not just version control support. Still, except for very few laudable cases, most research (not to speak of commercial developments) on IPSEs and other sw engineering tools is based (at best) on extensions to file system concepts. In 1981-2 I had observed at the Honeywell corporate research center people doing interesting work using Multics' RDBMS engine for sw engineering. I had hoped that things had progressed from that, but many sw eng environments are still pretty much behind that. Even interesting things like SHAPE are based on an AFS, which is an ad hoc extension to a file system. It is powerful, admittedly, but has all the obvious disadvantages of an ad hoc solution (and the idea behind it, described in a Stanford doctoral dissertation, was clearly intended to be just a clever improvement on filesystem system technology). Conversely, at least in principle, it would be much more interesting to use a true DBMS, e.g. Ingres, as a substitute for a file system, rather than viceversa (e.g. to store all the mass of unruly info currently contained in UNIX ad hoc "databases" like /etc/passwd, /usr/lib/sendmail.cf, etc...), or even for pathname resolution. The fact that there is not a single version control product on the market based on temporal databases might explain the lack of interest by software engineers. Or maybe you should have written "might be explained by the lack of interest". On the other hand, unfortunately I would be hard pressed to name a single widely used commercial temporal database management system. But at least research has been done on them, and there is understanding of the issues (and even some prototype implementation). As to version control, my reckoning is that the ad hoc approach still dominates (nothwithstanding some interesting work, like W. Tichy's a few years ago on and/or trees). For example, how many sw eng environents/tools out there do support as easily and obviously such DBMS features as: * transactions * recovery * auditing * schemas/data dictionary as part of the database itself * interactive ad hoc queries * 4GL interfaces * .... that are assumed as given when using a proper DBMS? My impression is that most sw engineering tools and environments around are still in the equivalent of Cobol+ISAM age... (or in the case of SCCS/RCS, the Librarian one). It's depressing to read so much drivel. :-(. Well, you could cheer up me and everybody else by being more specific and trying to provide some good example of the widespread influence of database research on IPSEs and sw engineering tools. I can easily think of isolated meritorious works (e.g. ASPECT), but I would really appreciate it if you could dispel my gloomy perception of the status of the mainstream. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk