On Sat, 19 Feb 2011, Eliot Miranda wrote:

> On Sat, Feb 19, 2011 at 11:46 AM, Chris Muller <ma.chris.m at gmail.com> wrote:
>
>>>> Well, will there be a very much code removed?  I'm hard-pressed to
>>>> imagine we would save even 1MB of disk-space.  But yet at the cost of
>>>> losing a continuity-of-record about Squeak; e.g., "what happened
>>>> between 4.2 and 4.3".  Each release should be presented in terms of
>>>> its delta to the prior release.  Isn't that a bad deal or am I missing
>>>> something?
>>>
>>> I'm not sure about what your goal is with that delta. Condensing the
>> sources
>>> is not bad, but IMHO it's late. It can be done now, but it's better
>> before
>>> releasing the image (it's not specific to 4.3).
>>
>> My goal is elegance, continuity, and useful information (deltas).
>>
>
> Elegance pushes for an empty or absent changes file.  Continuity and useful
> information push for a sources file that contains older versions.  I have
> code that condenses the changes while eliminating intermediate versions that
> are not ancestors of the current version.  See directAncestryOfVersions: in
> the attached changes.  How about we adapt this code to function for
> generating a new sources file, and generate a SqueakV4.2.sources?

Andreas added SmalltalkImage >> #appendChangesTo: during the developement 
of 4.1 which can create a new sources file (or modify the existing one), 
which will contain the contents of the original sources file + the latest 
version of all changes from the changes file. The contents of the changes 
file will be empty.


Levente

>
> VisualWorks has always generated a new sources file for every release so
> that the changes file is absent (the empty file serves no purpose).  But I
> also agree that old versions are great to have.  These two are not
> antithetical.
>
>
>>
>> It's elegant, for Squeak 4.2, to consist of:  a V41 sources file +
>> image + changes file.  This is the traditional essence of Smalltalk
>> systems; sources+changes, and one which provides a "continuity" from
>> one released image to the next.
>>
>> If we compress right before each release (instead of right after),
>> then wouldn't we just be deploying a "snapshot" of the state of the
>> system as of a particular moment in time.  There would be no
>> "connection" to the prior release at all in terms of what maturities
>> the system made.  And only because we wanted to save a couple MB of
>> disk space?
>>
>> I guess I should ask you to clarify your question you posed to me too;
>> what is your goal / reasoning.  You said, "it's late" and it's "better
>> before releasing the image".  May I ask why?
>>
>> I don't think disk-space is a good answer because someone interested
>> in a, as-small-as-possible is not going to use a stock Squeak release
>> anyway; they're going to have to do a unloading / condensing /
>> compression steps.
>>
>> Regards,
>>   Chris
>>
>>
>