Hello

On 2/27/13, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:

Quoting Frank Shearar frank.shearar@gmail.com:

...

...

?snip? The changes are at https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-F...

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

..

...

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