Hi Dan,
Long time no see.

I use the changes for two things:
1)
To pick up stuff that I had discarded earlier. Example: I want to use very 
large Arial fonts for talks. One way to install fonts is to use 
TTFontDescription>>addFromTTFile: . Another is to 
use  TTFontReader>>installTTF:asTextStyle:sizes:. There is also a bugfix 
suggested in e-mail http://minnow.cc.gatech.edu/squeak/2235 from Kris 
Gybels 2002-02-04. Suggesting that the depth should be set to one in 
TTGlyph>>asFormWithScale:ascender:descender:.  I thought my font project 
was completed, but discovered a flaw that made me want to retrack my steps 
to try something else. Not wanting to reinvent debugged code, I searched 
the change files until I found what I needed.

2)
To experiment. For example, when I wanted to discover how a balloon help is 
activated, or more precisely why it wasn't activated in a certain case, I 
examined the stack at different points in the process. At the crucial 
state, the stack was 29 activations deep, many of them reentrant and all of 
them obscure (to me). I had frequent crashes during this work, and used to 
changes file to recreate the situation up to, but not including, the last 
step. And then examine that step, modify it, and try again.

The reason why my work process is erratic is that I find it effective. I 
follow a main theme, but is happy to digress to improve my tools or to 
explore some niche in the system.

--------------------

I do not need the changes file to keep 'finished' packages etc. for my 
daily work. I keep them in my image. This is the best library there is, 
IMO. (Shipped products are still being generated by stripping the main 
image). If I start from a new release image, I use the workspace log to 
build a new system creation process. This is not automatic; I have to 
consider every step carefully to make sure my stuff will work properly in 
the new environment. So Monticello or an automatic versioning system would 
not help me. They overlap the information in my image.

I do see that the current change file scheme may be effective in some 
cases. I do not see why it is enforced deep down and wide around in the 
system. VW supports a maximum of 32 source files, the Squeak encoding seems 
to support exactly two. So that's that. I may remove the binding between 
image and changes names, however, but not today.

Best regards
--Trygve





At 07.03.2004 16:07, you wrote:


>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


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway