On 27.08.2010, at 19:26, Hannes Hirzel wrote:

> Bert,
> Somebody (you, Bert?) updated the class comment of MCMcmUpdater  one
> or two day ago.

It was Chris, I just committed his package to Trunk.

> It is now more comprehensive and answers many of the
> question. However some new come up. See below.
> 
> --Hannes
> 
> On 8/26/10, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> 
>> On 26.08.2010, at 08:13, Hannes Hirzel wrote:
>> 
> .....
>>> 2) Which object is meant here by 'configuration map'?
>> 
>> The update configuration loaded from the repository (e.g.
>> "update-xy.42.mcm")
> 
> Could you give an actual example of a configuration map with packages
> in the unloaded packages list? (I.e name config map xy uses packages
> p1, p2, p3)

Just open the trunk repo, scroll to the bottom in the left list, and click the "update" entry. There you see all the configs. Click "Browse" top open an mcconfig browser on any of them.

> I assume  it is a file in the repository?

Yes.

> And loaded into the image is it an instance of MCConfiguration?

Yes.

> Is the Monticello Configuration browser used to create them?

Yes.

> Why do I not see any of the configuration maps there?

Because they are in the repository. There is no config map in the image. It is only loaded from the repository when updating. 

- Bert -

> ==================================
> The current class comment of MCMcmUpdater
> ==================================
> 
> 
> MCMcmUpdater provides utility methods for updating Monticello packages
> from Monticello configurations.
> 
> When Monticello configurations are stored in a repository (or
> repositories), MCMcmUpdater acts as an update stream. It first ensures
> that each configuration map has been loaded in sequence, then updates
> the last configuration map to the most recent version for each
> specified package, and finally loads these versions to produce a fully
> updated configuration.
> 
> Currently if a set of packages are unloaded from the image, using this
> class to reload them may cause problems, depending on what
> dependencies those classes have.  Success is not assured.  Removing
> packages via SmalltalkImage>>unloadAllKnownPackages will be
> successful, it flags the packages removed so that they are not loaded
> by this utility.
> 
> If you wish to not have MCMcmUpdater update packages, there are two
> ways to handle this:
> 
> 1) To have MCMcmUpdater not update any packages not currently in the
> image set the UpdateMissingPackages preference to false:
> 		MCMcmUpdater updateMissingPackages: false
> 	Note that any new packages added to the repositories will not be
> picked up when this is turned off.
> 2) To have MCMcmUpdater not update a specific package, evaluate
> 		MCMcmUpdater disableUpdatesOfPackage: <packageName>
> 
> Class Variables definitions:
> 
> DefaultUpdateURL - String: the URL that will be checked by default for
> updates.  This would be set for a common standard location to check.
> 
> LastUpdateMap - Dictionary of Integer: version number of the last
> loaded update map per repository.  Keeps track of the last
> configuration map, so that the utility will not have to run through
> the full history in the repositories each time you ask to update.
> 
> SkipPackages - Set of Strings: names of packages to not update in
> MCMcmUpdater (empty by default).
> 
> UpdateMissingPackages - Boolean: if true (default), new packages in
> the update config map will be loaded unless they are in SkipPackages.
> If false, packages not currently loaded in the image will not be
> loaded by MCMcmUpdater.  (This can be dangerous if packages are split
> - use at your own risk).
>