On Wednesday, June 29, 2005, at 08:20 AM, Avi Bryant wrote:
On 6/29/05, Doug Way dway@mailcan.com wrote:
- Update cs #1: Full Monticello changeset. For now, I'm just using
Monticello-ar.245.mcz for this, which is the latest one in the Squeak3.8-Packages iSqueak image, because we want a version that works with MonticelloConfigurations. Or can we just use one of the base Monticello releases such as Monticello-avi.231 ? (Does the Reorg cs depend on a specific Monticello version?)
We definitely want one of the Impara versions, for the configuration support.
Ok, I'll go with the versions I mentioned for cs #1 and #2 then.
- Update cs #4: The partitioning DoIt cs (from http://source.impara.de
-> Projects -> iSqueak -> wiki).
Note that after I do these steps, the list of packages in the Monticello browser is somewhat different than in the Squeak3.8-Packages image, this may need some cleanup? Not sure where Connectors and some of the other packages came from. See attached screenshot.
I think those come from cs #4, right? Do we need to run that? I'm not sure we want all of those automatically created packages in there.
Yes, but I thought cs #4 did all of the other PI-creation as well, so I assume it is necessary. I.e. it creates the Kernel, Collections, etc MC packages from the class categories. Installing MC doesn't do this, does it? The Reorg cs does not do it, it only shuffles class categories around.
Anyway, I can go through the steps again with my image tomorrow (which I don't have with me at the moment), and see where these extra packages are coming from... I should be able to figure this out.
Hopefully we can do all of this cleanup through updates, so that people can continue to follow the update stream from a 3.8 final image if they want. Otherwise, we'll have to just tell everyone to download a new 3.9alpha partitioned image, which wouldn't be the end of the world, but it'd be nice to avoid that.
The other thing we'll need to generate will be a changeset that provides the ancestry metadata for all of the initial package versions, so that the MC working copies will be in the same state as they would have been if all the packages had been loaded from the repository (which will take a long time and we don't want to put people through if we don't have to).
Ok, that would be good. Mm, any suggestions on how I should do this? :-) Of course, most of the packages are really the "initial" package versions as you say, so they don't really have any "ancestry", right? E.g. we would have Kernel version 1. But there may be something missing that I should add in any case... as if it were loaded from the repository, I agree.
- Doug