>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