Hi avi,

> I don't store changesets in CVS, in any format.  I only store
> representations of complete packages.  So you don't explicitly mention
> removals, you implicitly mention them by not having that class 
> declaration
> exist anymore (and the tools for loading these representations figure 
> out
> that what in fact needs to be done is a removal, if that class is 
> still in
> the image but not in the fileout you're loading).
>
> The representations themselves work exactly as you're describing, ie, 
> what
> I store looks like
>
> MCClassDeclaration
>   name: #Foo
>   superclass: #Bar
>   ...
>
> so that you get an object representing the declaration, *not* actually
> create a class when you evaluate it.

:)

I can easily understand that for historical reasons, the chunk format 
was a
good answer for storage of smalltalk code. Now more than 30 years later
we can fix the problems of these stupid strings that prevent us to build
better tools.

I like what you do in Monticello. This is the way to go this way you can
manipulate any code entity.


More recently I also wrote a VW5PackageExporter, which uses the newer 
XML
format, puts in namespace and package information etc.  This version
didn't make it into the image, but if you need it I can point you to it.

No thanks I generate chunk format and trap error, analyse the stack to 
create superclass
on the fly to avoid to have to linearize inheritance. My point was more 
general.