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