Monticello addresses configuration management of Smalltalk code:
exactly reproducing the state of the code at one place and time in another place and time
tracking variations of the same code, so that changes made concurrently can be reconciled
How it solves the problem
Monticello relies on an external packaging system, usually PackageInfo. It records a series of snapshots of the code in a package as it evolves, as well as the ancestry relationships between snapshots. To load a snapshot into an image, it finds the differences between the state of package in the image, and makes the necessary changes to the image so that it matches the snapshot. It uses the ancestry of snapshots to provide a merge operation, so that conflicts between two sets of changes can be detected, and non-conflicting changes can be applied automatically.
For coherence I think the author should write the sections above this line.
People can add what they want to these later sections, and can suggest that the author change the rest.
What's cool about it
Monticello keeps enough ancestry information to do merges very well - much better than Store or ENVY. Even if you make repeated merges, it's able to correctly detect conflicts, which enables a much more natural style of collaborative development.
Monticello supports several different types of repositories for storing snapshots, so it doesn't require a lot of infrastructure to be used. It can use a local directory for offline work, a web server for sharing work between distributed developers or an object database for collocated teams.
What's not
The package model that Monticello 1 uses is too restrictive. It doesn't handle method overrides very well, and it's mechanism of dependencies between packages is also inflexible. These issues are addressed by Monticello 2