Let's move on from text-representation of behaviour!

danielv at tx.technion.ac.il danielv at tx.technion.ac.il
Wed Sep 29 17:59:06 UTC 2004


Maybe an MC-appropriate version of the changes file would be 
a .changes directory that has a file representing each modified 
WorkingCopy. These could be variants of .mcd files treating 
later definitions as definitive, to make the files incremental like 
the .changes file. 

Seems to me like this could be added without touching the
.changes file, so people can get used to it. I'm pretty sure I'd be 
using the new mechanism for recovery more than the .changes 
file myself.

Daniel

Colin Putney <cputney at wiresong.ca> wrote:
> 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



More information about the Squeak-dev mailing list