What I do when I run into these problems is to publish checkpointed sets of changes as different versions. The loading instructions specify that in order to migrate, say, package X version 3.0 (without changes) to 3.1 (with changes), one has to load 3.0.1, 3.0.2, ..., 3.0.k in sequence, after which 3.1 is loaded. So, in your case, k would be about 20. This has the nice side effect of clearly documenting each stage of the changes.

Luciano and myself did something similar for the hash changes back in 2000. At that time, 7 checkpointed changesets in the update stream changed the symbol table (and things like Symbol>>hash) under the running system. I never heard of any issues with that... hopefully there were actually none.

My 2 cents, Andres.

Eliot Miranda wrote:

Hi All,

I'm embarrased to say that part of my ork environment revolves 

around ChangeSets. While I very happily use Monticello I also have the Closure bootstrap strewn across a number of change sets, about 20 in all. Because the Closure bootstrap is complicated, with different variations for Squeak 3.9, Croquet etc, with different stages in self-modification of the compiler, etc, it can't be written as a set of Monticello packages.

But for the second time I am about to hit my changes file limit and, because of Monticello overrides and my own method history, I do not want merely to condense changes and continue. Instead what I want to do is move my change sets to a more up-to-date image. At Qwaq Andreas builds weekly images whose end result includes the result of the Closure bootstrap.

What I would like to do is serialize all my change sets, file-out all my changes (idelaly including history) and then in an up-to-date deserialise the change sets to preserve the structure, and selectively file-in those changes that are different to the up-o-date image (I haven't thought this last point through too carefully; presumably all the changes are in the up-to-date image, so what I really want to bring in somehow is the history).

What I wondered was has anyone else gone throguh something similar and if so do they have any code that would help me, war stories that would change my mind, or alternatives (e.g. how to preserve Monticello overrides through a condense changes).

AdvThanksance

Eliot

Hi Eliot!

Eliot Miranda wrote:

What I would like to do is serialize all my change sets, file-out all my changes (idelaly including history) and then in an up-to-date deserialise the change sets to preserve the structure, and selectively file-in those changes that are different to the up-o-date image (I haven't thought this last point through too carefully; presumably all the changes are in the up-to-date image, so what I really want to bring in somehow is the history).

Although I can not claim Deltastreams *currently* as being able to do the above just - this is EXACTLY the kind of situations it is intended to work with/for.

For example, Deltas are two-step - you first load them into the image, analyze them etc, then apply what you want using SystemEditor which does it atomically, etc.

So... anyone want to help out? :)

regards, Göran