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