<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Working together (some ideas)</title></head><body>
<div>Hi folks,<br>
here are some of my ideas on source code management and working
together in Squeak. Maybe this could be the basis for a better
modularization and configurability of Squeak images.<br>
</div>
<div>Hans-Martin<br>
</div>
<div>Hope you can manage the HTML. Netscape is fairly good at
producing an ASCII version, so I just send both formats.</div>
<hr>
<div><font size="+3"><b>Collage - A Source Code Management System for
Smalltalk<br>
</b></font></div>
<div>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.<br>
-- Hans-Martin Mosner <<a
href="mailto:hmm@heeg.de">hmm@heeg.de</a>><br>
</div>
<div>Note: The following text is written as if this system existed
already. Don't be fooled, most of it is still fantasy!<br>
</div>
<div><font size="+2"><b>Collage<br>
</b></font></div>
<div>I start by highlighting some of the features of traditional
Smalltalk source code management systems.<br>
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:<br>
</div>
<ul>
<li>.st files can change any aspect of the system, just as interactive
development could.
<li>ChangeSets are small and non-intrusive<br>
</ul>
<div>However, they do have some problems:<br>
</div>
<ul>
<li>Only the fact that something was added, changed or removed is
kept, not the actual source
<li>Unloading is not possible
<li>Versioning is not supported<br>
</ul>
<div>Larger Smalltalk projects are mostly done using the
industrial-strength ENVY systems. If you know ENVY, you know what it's
great plusses are:<br>
</div>
<ul>
<li>Proper version and configuration control
<li>Source sharing in a team
<li>Fast loading and unloading of applications and configurations<br>
</ul>
<div>However, it also has some shortcomings:<br>
</div>
<ul>
<li>It is big
<li>Changing (fixing) system classes is difficult
<li>Applications can not overwrite methods or class definitions from
other applications<br>
</ul>
<div>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.<br>
<b>Collage</b>, 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.<br>
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.<br>
Collage layers can be loaded and unloaded quickly by using the
ImageSegment technique for storing complex structures in a binary
file.<br>
</div>
<div>The Collage system within a Squeak image has a stack of top-level
layers.<br>
Top-level layers constitute packages or applications. They should be
mostly independent. Possible prerequisites should be stored as Gossip
items (see below).<br>
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).<br>
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.<br>
</div>
<div>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.<br>
</div>
<div><font size="+2"><b>Gossip<br>
</b></font></div>
<div>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.<br>
</div>
<div><font size="+2"><b>SCAN<br>
</b></font></div>
<div>The<b> Squeak Comprehensive Archive Network</b> would be a number
of WWW servers (probably modified Swikis) which mirror Collage and
Gossip items and serve them in different formats:<br>
</div>
<ul>
<li>Downloadable Collage files for loading Collage layers into an
image
<li>Downloadable Gossip files for off-line analysis and decision about
which layers you want to load
<li>HTMLized version of Gossip files for on-line lookup and search<br>
</ul>
<div>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.<br>
</div>
</body>
</html>