source.squeakfoundation.org (was Re: iSqueak)

[Bert Freudenberg]

Am 26.06.2005 um 13:22 schrieb Avi Bryant:

> On 6/26/05, Bert Freudenberg <bert at impara.de> wrote:
>
>
>> Please have a look at
>>
>>      http://tweak.impara.de/ABOUT/FAQ/MCConfigurationUpdates/
>>
>> Then ask back with any questions :)
>>
>
> My first question is about workflow: how often do you save a new
> config map?

Actually, in the Tweak update scheme we do not "save" a config map at  
all. When we post it to the update stream, it is not retained after  
loading packages. It is just used as a list of packages that need to  
be loaded.

Additionally, we have a global config map in the image, which is  
updated automatically by using the highest-numbered version found in  
the repository. This config map update is performed after updating  
from the update stream.

> Do you only do it when you either add or reorder
> packages, or need to post an intermediate update to the stream?

Yes, that's the current practice, because Tweak is still undergoing  
heavy development.

> Or do
> you save the config map for every stable configuration of versions
> (whenever all tests are green or whatever)?  It seems to be intended
> more for the former, particularly because the naming seems to be
> totally manual, whereas with the current dependency system I tend
> towards the latter.

True. We rely on the update-stream / config map hybrid, so previous  
config maps are only found in the update stream, not as explicitly  
versioned files.

> Do you tend to just have one version of the config map in the repo
> that you overwrite when things change, or do you end up with a lot
> with different names (which seems it would really clutter up the
> repository browser)?

As I said, we do not create config map files at all right now, so  
this part of the code is a bit underdeveloped. Our squeaksource  
version supports uploading of config maps, but we do not use this  
right now. When I experimented with this, I uploaded the updated  
config map under the same name. Locally, I even explicitely forbid  
caching of config map files because the name was not guaranteed to be  
unique.

OTOH, config maps are a lot like MCVersions, so they would benefit  
from the same naming scheme when they are stored in files. We might  
want to implement something along these lines, or actually go and  
merge versions and config maps into one (I imagine MCConfiguration  
and MCVersion could share a common superclass handling dependencies  
and naming, MCVersion would additionally have code, MCConfiguration  
would have repository info ...).

- Bert -