The Inbox: Monticello-cbc.399.mcz

>  ----- Method: MCPackage>>unload (in category 'as yet unclassified') -----
>  unload
>   "Flag this package to not automatically reload when updating from Trunk.
>   To begin receiving trunk updates on this package again, manually reload package."
> + MCMcmUpdater disableUpdatesOfPackage: self name.
>   ^ self workingCopy unload!
>
>  ----- Method: MCWorkingCopy>>merged: (in category 'operations') -----
>  merged: aVersion
>   ancestry addAncestor: aVersion info.
> + MCMcmUpdater enableUpdatesOfPackage: self package name.
>   self changed!
>
>  ----- Method: MCWorkingCopy>>loaded: (in category 'operations') -----
>  loaded: aVersion
>   ancestry := MCWorkingAncestry new addAncestor: aVersion info.
>   requiredPackages := OrderedCollection withAll: (aVersion dependencies collect: [:ea | ea package]).
>   self modified: false.
> + MCMcmUpdater enableUpdatesOfPackage: self package name.
>   self changed!

>> Also, this introduces a hard dependency on MCMcmUpdater into the Monticello package. So this should at least be protected using
>>
>>        Smalltalk at: #MCMcmUpdater ifPresent: [:updater | ... ]
>>
>> or using some other mechanism of decoupling.
>>
>> E.g., I see MCPackageManager class sends "self changed: #allManagers" whenever a package is added or removed. Maybe listening to that would be better than adding these explicit notification?
>>
>> - Bert -
>
> I'll look into the rest of this later tonight when I get a chance - a
> good time to understand more of the code.
>
> -Chris

> 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