Am 24.11.2005 um 10:29 schrieb stéphane ducasse:

> On 24 nov. 05, at 00:46, Bert Freudenberg wrote:
>
>> Nice summary - thanks for posting! :)
>>
>> I might add a few things:
>>
>> * Toolbuilder should not be necessary for using either Monticello  
>> or MCConfigurations
>> * the "upgrade" installation method is the most useful to me, it's  
>> smart about not clobbering versions that are newer in the image
>> * I use "upgrade" with the #upgradeIsMerge preference enabled,  
>> which lets me maintain my own local "branch" of a package while  
>> still staying in sync with the "official" version
>> * upgrading via config maps from an mcd-enabled SqueakSource  
>> server is many times faster than loading individual mzc packages,  
>> because the server builds a binary patch that is applied to the  
>> image without any snapshotting/diffing
>> * a configuration can be put in a global variable, then every day  
>> just say "MyConf updateFromRepositories; upgrade", or say "MyConf  
>> browse" to change it
>
> What we never understood with marcus is why there was not a  
> classVar or ClassVar dict to store configs.

Well, there is. For example, Tweak's current configuration is indeed  
stored in a class var.

It's just that in the way I use configs there is no need for a global  
list of configurations ever created / loaded / etc. There is no such  
thing as *the* configuration, which is why the Config Browser is  
empty when you open it. Configurations themselves are not versioned,  
so you would get an endless list of configurations when you work with  
them continuously. Packages can be in multiple configurations at the  
same time, which is different from the working copy of a package, of  
which there is exactly one in the image. Etc. pp.

If someone has an idea for a system and interface to manage multiple,  
possibly versioned configurations, I'm all ears. It's just that I did  
not need it until now.

Avi also had to say something about this (http://mail.wiresong.ca/ 
pipermail/monticello/2005-February/000121.html):

"From the point of view of architecture: what I think I'd ideally like
to see is a Configuration object that is completely separate from
Version objects, whose interface is very simple - it just returns a
list of versionInfos.  Versions themselves wouldn't have any
dependencies at all, loading and saving one simply means loading and
saving that package.  Then we could play with having a number of
different types of Configuration that found that list of versionInfos
in different ways - one that found the latest version of a set of
package names, one that had hardcoded versions, one that found the
latest version in a particular repository or on a particular branch,
etc.  It should be fairly easy to do that as a layer above all the
current version/workingcopy stuff so that it's not intrusive at all."


- Bert -