More generally, some of the losing changes/sources problem could probably be helped by the suggestions bandied aruond a while ago about putting the sources 'in the vm' in some sense (ie mac resource, windows resource, Acorn app.dir., unix links etc) and perhaps, by making releases that have condensed sources and null change logs (so it gets created on first startup rather than being looked for).
I was going for the minimum cognitive overhead. People are used to the idea of an "application & document" on their host OS.
VM = application image = document
Simplicity itself. Why hide the sources in the VM? Make them accessible and understandable from within Squeak. What could be eaiser to understand than having CompiledMethods having an instVar named 'source' that points to a string? What could be easier to extend than having a source pointer that points to an object?
One could always have a method that externalizes the sources, so people who understand the sources/changes mechanism could easily generate them.
I'm always seeing people new to Smalltalk doing things like starting an image from a directory other than the current working directory, and then saving image to a new name. It doesn't work right in squeak. The changes gets copied to the original image directory, but the new image gets saved in the current working directory. (VW can't even find the changes file BEFORE saving).
-- Mike Klein
squeak-dev@lists.squeakfoundation.org