From: David A Duff
Subject: Interfacing lisp with a source code control system
Date:
Message-ID: <10961@steinmetz.ge.com>
Has anyone thought about the problem of interfacing lisp with a source code
control system?
Ultimately, I would like to have the kind of capability that the symbolics
provides (systems, patches, etc.), but I would settle for just being able to
define a "cut" or a set of specific versions of a set of files that define a
certain level of functionality (e.g. the "working" version, the "experimental"
version, etc.).
I would like for it to be portable, if possible, but I think that may be
asking too much.
At a lower level, the kind of things that I think would be needed are:
- interface to sccs.
This should be pretty easy, and there seems to be an external program
interface that is becoming standard across different lisps, (it is the similar
for ExCL and Lucid, at least) so it might even be portable.
- define some functions for loading and compiling a particular sccs version
of a file.
Here is would nice to be able to compile/load from a stream rather than a
file. Such functions must exist, but I'm afraid there's no "portable" way of
doing this, since this is not defined in Steele.
Another alternative would be to just have sccs create temporary files and do
loads/compiles on them. It would be nice to have a mechanism for recording
the sccs version along with the normal source file recording, so that it would
be possible to tell for any function exactly which version of which file
contains its source.
- define some higher level data structures for keeping track of systems,
modules, dependencies, etc. A symbolics defsystem-like utility is what I'm
talking about here. The defsys distibuted by ·····@eddie.mit.edu, and the
defsys distibuted with pcl, are other examples that are publicly available.
Perhaps they could be modified somewhat to take advantage of sccs.
I'd appreciate hearing any ideas or suggestions. Now that unix machines are
starting to be used for lisp development, I'm sure others must have looked
into this problem...
Dave Duff
GE Research and Development Center
Schenectady, New York 518-387-5649
····@eraserhead.steinmetz.ge.com, ·····@ge-crd.ARPA,
or uunet!steinmetz!eraserhead!duff