links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Summary: Monticello 1
Last updated at 2:42 am UTC on 1 September 2015
Reported by Colin Putney

What problem is being addressed

Monticello addresses configuration management of Smalltalk code:

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.

Useful links


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

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


More what's not cool about it.

Monticello 1 repurposes method categories. This is cool because it allows methods to belong to a different package than their class. This is uncool because in the process it early binds all method coding to considerations of which package they belong.

So Monticello 1 in the context of a new young package allows you to keep methods that are the packages responsibility together in one place.
In the context of old packages which are integrated into a larger whole it fails in several ways.
For maintaining images Monticello 1 becomes an out of sequence tool.
Out of sequence tools require designers/coders to backtrack an retrace their steps
to correct problems.
When people mention overrides here, they are not talking about a subclass redefining
a super classes behavior. They are talking about packages redefining the method often of a core class.

Because Monticello 1 gives new and critical meaning to method catagories it kills the ability to use changesets to make changes. The problem being that changing a method will often save out the whole of that methods class organization. Time passes. Then the changeset gets read back in. The ancient organization replaces the current organization. The classes most likely to be affected are often the most core. Adding a fallback method to Object or Morphic often trigger this.

So having Monticello 1 as a packaging system means


Back to New Modules