> getting rid of the changes file). Then, saving an MC version is merely
> a matter of noting the current versions of all the classes/methods in
> the MC package, 

Yea persisting object-representations of the code-domain directly would be real
nice; it would eliminate all of the redundancy and wasted disk space that comes
with building a new mcz every time.

While Magma can currently be used as a Monticello repository out of the box,
but I doubt whether the redundancy is eliminated because I think Monticello
builds an entirely new object-structure to fully represent each version, there
is no sharing.

> It gets hairy when I start to think about multiple images being
> connected to the db - how do you keep your stuff apart? I haven't
> thought much about all that, so therefore an RFD here. If people have
> ideas to share, or comments on the code, I'd be delighted to hear it.

How often do you want the 100th version ago of a method dated back forever?  I
actually kind of like how getting a new image starts clean with all of the
method histories.  I usually only care to know what I've been doing *lately*. 
As great as ENVY was, I don't really miss it; Monticello is too good.

BUT it is short the same thing that ENVY was missing; object resources.  While
Magma can deliver an arbitrary object-model with a Monticello code repository,
there is no associating versions of code with versions of the object model..

 - Chris