Hello

On 2/27/13, Juan Vuletich (mail lists) <juanlists at jvuletich.org> wrote:
> Quoting Frank Shearar <frank.shearar at gmail.com>:
>
>>> ?snip?
>>> The changes are at
>>> https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-FixRecentMorphicSlowDown-JuanVuletich-2013Feb26-22h41m-jmv.1.cs.st
>>>
>>> Cheers,
>>> Juan Vuletich
>>
>> Ah, I see. Thanks; I hadn't thought to look elsewhere in the repository.
>>
>> Also, that confirms my suspicion that the way Squeak/Cuis updates work
>> is analogous to a database migration: take some big chunk of state,
>> and mutate it in these specific ways.
>
> Well, that´s the way the Cuis image is updated. It is the same as the
> "update stream" Squeak used to have.
>
>> The problem being that to see what actually changed requires something
>> in the state induced by #1618, applying the 1619 changeset, and
>> comparing the #1618 state with the #1619 state.
>
> Yes. Not a problem in my view. To me, the best way to understand the
> behavior at levels #1618 and #1619 is to run the system updated to
> those levels, and use the Smalltalk tools to study it. I.e. I´m a
> classical smalltalker.
>
> BTW, for external packages, we store the full code in a format GitHub
> can understand, version, diff, merge, etc. See, for example,
> https://github.com/bpieber/Cuis-StyledTextEditor/commit/e01cf430657739bfcca197fc9bb1d872e30dd3a2
>
> ..
>
>> I don't mean this as a criticism - I'm jut formalising my
>> understanding of how we actually work.
>>
>> frank
>
> Criticism is welcome too. I´d really like to have something better for
> the base image, while keeping the nice properties of ChangeSets and
> the update stream. Maybe using DeltaStreams instead of ChangeSets
> would be an option. We´d need to see how to make GitHub ´understand´
> them.
>
> Another option would be to commit, in addition, a condensed Sources
> file each time, to let GitHub diff that?

I think this would be worth trying. Commits of an updated condensed
sources file after a couple of changes or even after each change set.
Or a log file which shows the old and the new code.

--Hannes