Quoting Mark Guzdial <guzdial at cc.gatech.edu>:

> 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.

Hi Mark,

I completely agree that crash recovery via the .changes file is important. I
rely on it quite a lot as my experiments with Behavior tend to crash the VM.

What Diego was suggesting, and what I hope to implement, is to change the role
of the .sources and .changes files. Right now, they are the primary repository
of source code - as we browse the system and make changes, method sources are
shuttled in and out of the image via RemoteStrings. The .sources file is just a
way of keeping .changes from getting unworkably large.

What I want to do is replace the .sources file with a Monticello repository, so
we don't loose history everytime we condense sources, and turn the .changes
file into a true journaling system. If it doesn't have to serve as a source
code repository, we can focus on making it as robust as possible, while also
eliminate the need to ship around tens of megabytes of source code with our
images.

(As an aside, a variation on the scheme I mentioned in my last mail would be to
empty the journal every time a Monticello version is saved or loaded rather
than  on image save. That way there's no chance of loosing code if an image is
corrupted on disk.)

So, in short, the idea is not to abandon journaling, but to make journalling
independent from code storage.

Colin