We've switched to MCC, thought that I'd write a quick how-to. MCC is 
simple, but the UI isn't (yet) intuitive. I found this out by 
trial-and-error, it works for me, but it's hardly authoritative:

I loaded from http://www.squeaksource.com/ToolBuilder 
ToolBuilder-Kernel-ar.14 ToolBuilder-Specs-ar.1 
ToolBuilder-Morphic-ar.17 and from http://source.impara.de/mc 
Monticello-bf.271 MonticelloConfigurations-bf.34

I have a config map for that, but that's a bootstrapping problem ;). 
This will also give you some nice updates in Monticello, especially a 
creative use of fonts for package state - recommended in any case.

Now, the first configuration - open a Monticello Configurations 
browser from the world menu. The empty browser has three panes:

- packages
- repositories
- selected package info.

Add the repository/repositories you want the config map to check by 
rightclicking in the middle pane. Add the packages in the top pane, in 
the correct load order. Store the configuration. Done. You can now 
load, for eternity, exactly this configuration :).

To load an existing configuration, open the repository containing it, 
navigate to the configuration, and select Browse - this will open the 
MCConfiguration browser again.

To install this configuration into memory, there's the load button. 
You can load, merge or upgrade - I can understand what the first two 
do, I haven't checked the third option.

To bring an older configuration up-to-date, use the Update button. If 
you update from image, the configuration will be updated to reflect 
what is in the image; if you update from the repositories, the 
repositories will be scanned and the latest versions will be set in 
the configuration.

Workflow suggestion:

- In the morning, open the configuration and "update from 
  repositories", "install". This'll give you everything your 
  colleagues checked in last night while doing overtime (while you 
  were at the pub with that girl from HR, remember?);
- Just commit single MC versions, like always.
- In the evening, just leave.
- When building a release, when you have all the components in memory, 
  "update from image", "store". Choose an appropriate name and you'll 
  always be able to find that particular version back if a customer 
  needs support.

The idea is that you don't normally need to store config maps all the 
time - usually, if everybody integrates all the time, you can just 
grab any old map and do an update from repositories to bring it 
up-to-date dynamically before installing it. I think this works better 
than saving config maps all the time, it clutters the various browsers 
and adds little value. If people branch for extended periods, let them 
use their own MC repository so your config map won't pick up this 
unintegrated stuff.

Cees

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

- Bert -

> Would you mind going in a bit more detail what upgrade does?

It loads/merges (depending on the upgradeIsMerge pref) only versions 
that are not ancestors of the working copy. Because if the version 
from the config map is already an ancestor of the working copy, it 
should neither load nor merge it again.

>> * 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
>>
> Ah, that's cool - upgrading is a bit slow at times. So you recommend
> to switch to mcd and the upgrade method to stay in sync?

There's no need to "switch" - just upload an mcz as before:

http://impara.de/pipermail/tweak/2005-May/000772.html

Also, this works with all three install methods (load/merge/upgrade) 
as long as the working copy is unmodified. If it is modified, the 
normal snapshotting and diffing is performed (but it still only 
downloads the .mcd which should be a little faster).