[squeak-dev] The Inbox: Monticello-cbc.399.mcz

Bert Freudenberg bert at freudenbergs.de
Thu Aug 26 09:33:57 UTC 2010


On 26.08.2010, at 08:30, Chris Cunningham wrote:

> Ok.  I've looked at this some more, and it is interesting.
> 
> First, workingCopy, I think I still want to tap in at #unload. The
> notification that goes out seems to go out to the class after unload
> (part of unregister) after the package is removed with no notice of
> what was removed - so unless I keep a copy of all the MC working
> copies, I don't think I can trap what was removed.
> 
> Actually, for the load, the situation is similar - all of the users of
> changed: #allManagers just get the update and refresh their working
> list with all of the packages in the system - brute force, but makes
> sure there aren't any holes anywhere.  Still, that doesn't help in my
> case - I need to know exactly which package was loaded or unloaded.  I
> guess I could grab the full list of all packages in the image and make
> sure those aren't in the SkipPackages list.  I don't really like that,
> though.
> 
> The other interesting this is that if you drop the 'working copy', the
> code stays in the image, but the 'package' is dropped.  Should this
> still update from Trunk, or should it not?  If I used the changed:
> #allManagers trick, the results would be not updating these packages;
> if I intercepted the message, it would continue to update those
> packages (code).
> 
> On a somewhat unrelated topic, there doesn't appear to be any way to
> unload packages from the Trunk mechanism.  So, if we ever decided to
> drop a package altogether, or split the original package into several
> new one and remove the original one, that would require a non-trunk
> process to handle.  Not critical, just an observation.
> 
> -Chris

Thinking about this more I would not automatically add unloaded packages to the skip list, nor remove them when loaded. People mucking with this should know what they are doing, and will discover the skip list on their own.

Instead, only add them to the list in unloadAllKnownPackages, which is the only "semi-supported" use case for now.

And this will not require changes to Monticello itself, so all is well.

- Bert -





More information about the Squeak-dev mailing list