Collage and SCAN (project on hold )
Last updated at 1:35 pm UTC on 28 March 2004
This project is on hold. It has been replaced by SqueakMap, a project with a similar aim.
A Source Code Management System for Smalltalk
These are my ideas on a novel way of organizing Smalltalk applications such that they can be versioned, easily loaded into and unloaded from a base image. This is inspired partly by my daily work with VisualAge and ENVY, partly by earlier work on a source management system that we developed at Georg Heeg (AppMan). Some of the ideas come from what these systems don't do but should.
Hans-Martin Mosner <firstname.lastname@example.org>
Update on SCAN: The SCAN server is running and serves its own source now. http://squeak.heeg.de:8080/
Note: The following text is written as if this system existed already.
Don't be fooled, most of it is still fantasy!
But if you think it should become reality, vote on my What if you had... page.
I start by highlighting some of the features of traditional Smalltalk source code management systems.
In the beginning, there was the .st file and the ChangeSet, and this is what we Squeakers still live with. ChangeSets and .st files are a good way of organizing small packages which can be loaded on top of a mostly clean image. Their bonuses are:
However, they do have some problems:
- .st files can change any aspect of the system, just as interactive development could.
- ChangeSets are small and non-intrusive
Larger Smalltalk projects are mostly done using the industrial-strength ENVY systems. If you know ENVY, you know what it's great plusses are:
- Only the fact that something was added, changed or removed is kept, not the actual source
- Unloading is not possible
- Versioning is not supported
However, it also has some shortcomings:
- Proper version and configuration control
- Source sharing in a team
- Fast loading and unloading of applications and configurations
You could compare the way an ENVY Smalltalk image is built to a jigsaw puzzle: All the parts have to fit together, but they must not overlap. This works fairly well for closed projects where you can assign the work to different people, and they can talk about overlaps and possible redundancies to sort them out. For independently developed applications and base fixes, this is much more difficult.
- It is big
- Changing (fixing) system classes is difficult
- Applications can not overwrite methods or class definitions from otherapplications
Collage, on the other hand, is designed around the metaphor of a stack of overlapping layers, which may partially or completely mask underlying layers. Elements in collage layer are a superset of the things that can go in a .st file or ChangeSet: they may be a class or method definitions, changes or removals etc. But Collage elements could also be inst var or class var additions, removals or renamings, class renamings, pool and pool var definitions.
In the case of conflicting definitions, the uppermost layer wins. This is just like the way .st files work. But you can reorder or even uninstall layers, thereby unmasking previously masked definitions.
Collage layers can be loaded and unloaded quickly by using the ImageSegment technique for storing complex structures in a binary file.
The Collage system within a Squeak image has a stack of top-level layers.
Top-level layers constitute packages or applications. They should be mostly independent. Possible prerequisites should be stored as Gossip items (see below).
Top-level layers have an internal collection of sublayer which constitute the different patch levels of a layer. Whether top-level layers should have major versions remains to be decided; probably they should, especially when forking for parallel development and bug-fixing is desired. (In addition, loading 100+ patch layers might be a little slow).
Sublayers can contain the elements listed above, plus some internal changes such as undos of elements defined in a previous sublayer of the same top-level layer.
Collage layers can be loaded into an image without installing. There exists a mechanism to execute any number of layer installations/uninstallations/reorderings atomically, which would make it possible, for example, to switch between alternative compatible implementations of system-vital packages.
In addition to the stable versions of applications, you need meta-information which probably emerges only after an application has been versioned and released. This includes known bugs and incompatibilities, prerequisites, documentation etc. The main difference to the normal textual bug information is that Gossip items have a formal structure, which makes automatic reasoning possible. Gossip items have authorship so that you can probably weight them according to the people who wrote them. There would also be some sort of second-level Gossip, which probably supports, refutes or revokes earlier Gossip when more information becomes available.
The Squeak Comprehensive Archive Network would be a number of WWW servers (probably modified Swikis) which mirror Collage and Gossip items and serve them in different formats:
Collage and Gossip files could be digitally signed by their author to avoid problems with tampering. Some way of uploading must exist for authors to get their stuff into the SCAN.
- Downloadable Collage files for loading Collage layers into an image
- Downloadable Gossip files for off-line analysis and decision about which layers you want to load
- HTMLized version of Gossip files for on-line lookup and search