Lex wrote...

>For the record, Squeak's method and changes files work the way you
>describe, and it should be possible to make multiple images use the same
>changes file.
>
>I don't know what the UI for sharing changes files should be, however.
>In fact, the idea mildly bothers me, because it complicates an
>already-complicated model.  I would like to move in the other direction,
>and not have the changes file appear to the user at all.  I'd rather we
>had some sort of "snapshot" file which included both image and a changes
>log.

Also for the record, this is precisely what internalizeChangeLog does, or did 8 years ago.  I dreamed this up as a way to keep changes well-supported while moving from one file system (Mac Toolbox) to another (Squeak cross-platform) in the earliest days of Squeak.  Scott implemented it, and it has occasionally been of great value.  It is the only way to fly when files are not available for one reason or another.

This gives you all the benefits of a changes log *except one*:   namely the security of changes written on the disk and not lost if you crash.  Therefore if you use this mechanism in serious development, you must remember "Never to play for more than you can afford to lose" or, in other words, to save often.

	 Dan

PS:  To go further in the direction Lex desires, it might be reasonable to dribble the changes to a file, but to pull a compressed (*) and condensed copy into the image before a snapshot.  This would keep the crash survival benefit, while minimizing the in-image space cost, and keeping a user model of one file only.

(*)  the compressed sources mechanism I did a while back is actually designed to be incrementally writable as well as serving as a read-only sources file.  I'd be willing to test that capability if someone turns out to care about it.