Am 26.06.2005 um 13:22 schrieb Avi Bryant:
On 6/26/05, Bert Freudenberg bert@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 -