[etoys-dev] Preparing for Monticello-based updates

[Bert Freudenberg]

On 20.04.2010, at 03:32, David T. Lewis wrote:
> 
> So now I can browse both the Etoys repository and the Squeak trunk
> repository, and everything looks fine. I can see that a number
> of "FixUnderscores" have already been done on Etoys packages, so
> I see those differences relative to the base Etoys-to-go image,
> and everything else looks pretty much in sync as expected.

Hmm, don't we need to do a full re-categorization first before creating the real packages?

We need to account for every last method. Damn, I had code to check for that but didn't save it apparently ... oh well.

Karl, I filed out the reorg you did in your dev image (the one linked on the wiki) and added it to my "loadmc" script. It's included in the new zip below. So applying this should reflect the current state of re-categorizing.

The zip also has some more compiler changes from Eliot (literal byte-arrays), which was necessary for Installer to load.

> Most likely adding the Monticello-based update stream would be a
> good next step.

Almost, yes.

We still need to refine the categorization. I had a crazy idea: in the trunk image, generate a list of which class is in which category, same for all methods. Then recategorize everything in the Etoys image to match that (provided the class/method exists). Since this only recategorizes, it should do no harm. Could that possibly work?

Also, we need to add some code that creates actual MC working copies for all the packages. That would be the initial set of "real" packages which will need to be committed to the repo.

> [Off topic: I assume that the idea is to switch over to MC for development,
> although I have to say that I personally like Edgar's idea of *also*
> providing a changeset based stream generated from the MC changes. However,
> I don't know that we have a fully usable implementation of this.]

I have been playing with the idea to keep a traditional update stream in place as fall-back ... in case some surgery is needed that would be infeasible with MC updates.

Where would you see the need for a full changeset-based update stream? Seems cumbersome to me having to maintain both, with little benefit.

>> Comments and help welcome :)
> 
> It looks good so far :)
> 
> Dave

Thanks for testing!

- Bert -

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : loadtrunkmc2-bf.zip
Dateityp    : application/zip
Dateigröße  : 71738 bytes
Beschreibung: nicht verfügbar
URL         : http://lists.squeakland.org/pipermail/etoys-dev/attachments/20100421/82cf3c6f/loadtrunkmc2-bf-0001.zip