Am 07.07.2005 um 08:35 schrieb Andreas Raab:
Hi Doug -
In Tweak we have basically a fixed load order (==configuration) which originates from the configuration used in the original build. But the main reason for wanting to have a well-defined load order is that typically, if there are sets of cross-package changes, they follow already established dependencies.
Yes, makes sense. That should reduce the need for special update changesets to load packages in a special order.
Yes. That's another implicit advantage - most of the time stuff just "works" by loading the latest package versions.
Indeed - given that you have a "managed" repository, which has a linear numbering scheme and everyone agrees to merge in the latest version (so that when you upload v.n+1 it has v.n as ancestor). Maybe one could use squeaksource's blessing feature to enforce that.
So if you have cross-package changes, you just post all of them, and the load order is defined by the stored configuration (see below).
Any suggestions on how I should implement this? I guess we could just have a method defined somewhere (in the load-updates code) which has a hardcoded, ordered list of the 35 package names. I guess this list won't change very often. (The 3.9a-6676 image doesn't seem to be hanging onto the MCConfiguration instance that was loaded in update #6676, otherwise I might try to use that.)
That "hardcoded, ordered list of the 35 package names" would just be like the literal configuration that you issue as changeset (without the #upgrade call), but put into a method. It is precisely that literal representation why the configuration is as simple as it is now (compared to a full-blown MCVersion). It just defines a load order for a few packages, that's all :)
What we've done so far is to have a global which stores the latest version of a configuration and then just works issuing a "updateFromRepositories". It's very simple stuff - if you are curious check out CProjectBuilder>>loadUpdates and updateFromRepositories.
Yep, this works nicely in Tweak. Pasting the methods below for easier reference. I stripped out the progress display and logging.
loadUpdates TweakUpdateStreamManager loadUpdates. "from update stream" self updateFromRepositories.
updateFromRepositories | map | map := self defaultConfiguration. [map updateFromRepositories. map upgrade. DefaultConfiguration == nil] whileTrue. "repeat if we have a new map"
defaultConfiguration ^DefaultConfiguration ifNil: [ DefaultConfiguration := MCConfiguration fromArray: #( ... )]
There is a hook to set DefaultConfiguration to nil whenever the #defaultConfiguration method is recompiled (but this relies on Tweak semantics). Alternatively, you might have a class-side #initialize method that contains the new configuration, so it would automatically get overwritten after an update, and you test for map identity in #updateFromRepositories rather than testing for nil.
The call to #updateFromRepositories in #loadUpdates might possibly be guarded by a "bleeding edge" preference. That way, normal users only would get the "stable" configuratons explicitly posted to the stream, while the system developers would get all the latest packages from the repository.
- Bert -