I agree this too is "hard" and agree that for any useful image based
system there
needs to support for a limbo state. 

Allen Wirfs-Brock wrote:
> 
> Actually, what's really hard is what Team/V called "migration".  That is
> taking a module or set of modules and atomically replacing them with
> different versions of the same modules.  Envy does something similar.  In
> VisualAge Java they call it "replace".
> 
> While it's hard, I see this a pretty essential operation in a collaborative
> development environment.  It's one of those things like working with
> incomplete or inconsistent modules that isn't strictly necessary for
> deployment but is integral to incremental development.
> 
> Alllen
> 
> At 09:06 PM 8/20/2001 -0400, Dave wrote:
> 
> >1. The mechanism for unloading is indeed a good deal more complex than
> >loading and was one of the throny problems OTI had to address in
> >building embedded Smalltalk and Java.
> >
> >Perhaps the issue of unloading is something to be deferred until after
> >the basic module and component mechanisms are defined and tested?
> >
> >2. To my knowledge the only existing system that supports current
> >execution of multiple versions classes/methods is MS.NET with their
> >assemblies. This itself gets problematic however if you want to run
> >shared assemblies. I posted the references earlier for those interested
> >in the problem.
> >
> >Regards,
> >Dave
> >
> >
> >Les Tyrrell wrote:
> > >
> > > ----- Original Message -----
> > > From: Dan Moniz <dnm at pobox.com>
> > >   > I'm imagining that when you file in a ChangeSet (let's say Foo.cs)
> > >   > into your image (Bar.image), your image is writing out information to
> > >   > it's Bar.changes file that reflect the things Foo.cs is doing to your
> > >   > image. Then, to back out, you could use a currently fictional "Undo"
> > >   > feature which would allow you to back up steps as recorded in
> > >   > Bar.changes
> > >
> > > There are a few things that would need to be done when unloading a
> > module.  For
> > > one, you would like a rapid way of gc'ing or otherwise mutating any
> > instances
> > > defined by that module.  Then, you will want a rapid way of removing the
> > > definitions found in that module.  ChangeSets are no better, and no
> > worse, at
> > > doing this than any other scheme.  There is no need to iterate over a
> > change
> > > log- the ChangeSet already has an accounting of what it has
> > modified.  So would
> > > an OasisModule, or a Collage Layer.
> > >
> > > However, while associating a ChangeSet with either a Collage Layer or an
> > > OasisModule seems reasonable to me, trying to warp ChangeSet into
> > becoming more
> > > like these things does not seem reasonable.
> > >
> > >   > This may necessitate modifications to userland tools to deal with
> > >   > .changes file, and perhaps some modification to the information
> > >   > and/or format of information stored in .changes files, but I don't
> > >   > think it would be too drastic and I don't think it would have much
> > >   > with the implementation of ChangeSets themselves.
> > >
> > > What's wrong with the idea of implementing the roles of a Components and
> > > Modules?  In Oasis, a Module is a component that keeps track of Shared
> > Globals,
> > > Undeclared variables, Pools, and a few other things.  ChangeSets don't
> > do this.
> > >
> > > The role of a changeset is to keep track of changes... the role of an
> > > OasisModule is to act as a place in which those changes take
> > effect.  These are
> > > separate roles, so I would not reccomend mixing them.  ChangeSets are
> > just fine
> > > the way they are, at least in the sense of the scoping of their
> > responsibilities
> > > to tracking changes, and no more.
> > >
> > > Using ChangeSets as a means of identifying chunks of code to turn into
> > a package
> > > is another issue, as far as I know there is nothing wrong with that.
> > >
> > > - les