I'm sorry that I missed the beginning of this thread, to better 
understand WHY we would want to do away with the .changes file.  I do 
know how much we'd miss the .changes file here.

Novices break Squeak, at a pretty deep level.  We have at least 75 
students who take our second-year undergraduate required course EACH 
SEMESTER, and several of those do corrupt their images.  (We recently 
had a case of a Ph.D. student here corrupting his image so deeply that 
it couldn't be saved, and we had to go bit-spelunking to retrieve code 
that he desperately needed from workspaces!)  With the .changes file, 
these corruptions are no more than a minor annoyance -- you recollect 
your code from .changes, and plug it all into a new image.  Without a 
.changes file, a crashed and corrupt image means restarting one's 
project.  Since Murphy's Law requires that all such errors must occur 
12 hours before the homework deadline, the .changes file is absolutely 
critical to our students.

Mark

On Sep 27, 2004, at 9:40 AM, Colin Putney wrote:

> Quoting Diego Gomez Deck <DiegoGomezDeck at ConsultAr.com>:
>
>> This idea is the base for a lot of changes we need to do:
>>
>> - Store the sources *inside* the image.  The string is also an object,
>> isn't it?
>>
>> - Let use a .changes files ONLY to store the changes not present in 
>> the
>> image.  The .changes has to contains only the modifications made to 
>> the
>> image but still not saved.  That means, for instance, every time we 
>> save
>> the image the .changes goes empty. Note that .changes concept don't
>> implies text-format, the .changes can be a stream of serialized 
>> command
>> to impact on the image.  For example, all the changes made in the 
>> image
>> but in browsers can be saved (like all the changes a normal user can
>> make to an image just using the UI).
>
> Hi Diego,
>
> Actually I've done some work on this already, as part of a new 
> packaging system
> for Squeak. The idea is to store behavior as parse nodes in the image 
> rather
> than as text on disk. Then the .changes file would become a series of
> serialized SystemChangeNotifier events, and would be cleared when the 
> image is
> saved. On start up we'd check the .changes file and automatically 
> bring up a
> "recently logged changes" browser if it's not empty.
>
> The main trick is to do this without breaking the VersionsBrowser or 
> loosing
> method history. I think Avi's Unstable Squeak experiment will help in 
> making
> Monticello suitable for tracking source code evolution.
>
> Colin
>
>
>
>
>
__________
Mark Guzdial : Georgia Tech : College of Computing/GVU
Atlanta, GA 30332-0280
Collaborative Software Lab, http://coweb.cc.gatech.edu/csl
http://www.cc.gatech.edu/~mark.guzdial/