Steve Wart wrote:
> 
> 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.

Well, I was just illustrating a point -- backing up image and changes
files before every filein is (normally) way overkill. But in the absence
of any other mechanism I actually do this from time to time. I also keep
a clean set of fully updated image and changes files tucked away, so I
can just copy them to another directory, then filein and modify the
working copy as much as I wish without worrying about it screwing up -
I'm only about 10 seconds from restoring the image back to it's
"original" state.

-- Dwight