Smalltalk › Squeak › Squeak - Dev

[squeak-dev] living in the stone age; change set migration tools anyone?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Eliot Miranda-2

[squeak-dev] living in the stone age; change set migration tools anyone?

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

Andres Valloud-4

Re: [squeak-dev] living in the stone age; change set migration tools anyone?

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
>

Bert Freudenberg

Re: [squeak-dev] living in the stone age; change set migration tools anyone?

In reply to this post by Eliot Miranda-2

On 23.03.2009, at 04:39, Eliot Miranda wrote:

> Hi All,
>
> I'm embarrased to say that part of my ork environment revolves
> around ChangeSets.

Hehe. You are not alone. I'm working with some of those stone age
people, too ;) They even find Monticello needlessly complicated, the
practice of having to reorganize method categories obnoxious, and on
top of that those packages are less flexible than change sets.

I personally find MC much better suited for distributed development
than change sets, but it's hard to convince them given that they think
they would only lose power and gain nothing but ugliness.

> 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,

I'd like to hear those stories, too. And ideas on how to work with
both change sets and Monticello (or more specifically, how to keep up
with newer squeak.org releases in an image managed by change sets).

> or alternatives (e.g. how to preserve Monticello overrides through a
> condense changes).

Now that's simple, and should actually be fixed for a long time:

http://bugs.squeak.org/view.php?id=2514

- Bert -

Göran Krampe

Re: [squeak-dev] living in the stone age; change set migration tools anyone?

In reply to this post by Eliot Miranda-2

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