Another alternative is to consider implementing a (non trivial)
persistence/transaction system.

GS Smalltalk has this, and it becomes quite indispensable; something screws
up, you do an abort, everything is the way it was.

It changes the way you do change tracking & stuff like that, however. If
your image crashes, for example, all the changes you have committed are
safe. So your change set, instead of hanging on to the context to reproduce
the change, can hang on to the context to undo the change.

There is open source transaction code in the Postgres distribution.

Although this may sound like overkill, it's more elegant than Dwight's
suggestion of backing up the image before every file-in.

Of course the transaction stuff could possibly be useful for more than just
file-ins :-)

Steve (be kind, it's early :-)

> -----Original Message-----
> From: Dan Ingalls [mailto:Dan.Ingalls at disney.com]
> Sent: September 1, 1999 12:07 AM
> To: Dick Karpinski
> Cc: squeak at cs.uiuc.edu
> Subject: RE: More Benchmark Results + Problems with Win32/WinCE VMs
>
>
> >A second mystery to me is why Filein operations are irreversable.  What's
> >the problem?  I know how to write the reversing instructions
> when I do the
> >damage in other systems.  Why do people put up with being unable
> to retreat?
>
> Why do you add this holier-than-thou spin to an otherwise
> reasonable question?
>
> First, although, as Dwight points out, a fileIn can have any kind
> of executable code in it, most are pretty well behaved
> (add/remove methods, instVars, classVars, classes), and most of
> these changes could be reversed without a huge amount of
> bookkeeping.  It might be worth doing.
>
> Second, there is the nascent capability to isolate projects with
> regards to many such changes.  So one could open a new project,
> try out the fileIn in it, and then assert the changes throughout
> or remove the project depending on whether the results were
> favorable.  This mechanism cannot currently isolate all possible changes.
>
> Now to answer your rhetorical question.  The reason people put up
> with things the way they are is that Squeak's save/restore at the
> image level is usually simpler, faster and more effective than
> any of the alternative undo schemes we have considered.  It's
> quite possible, though, that it should be packaged and presented
> better so that you don't feel so bereft of even the most basic support.
>
> 	- Dan
>
>