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:
- 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.
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
- Methods get lost between packages.
- Methods get redefined and appear in several packages at once.
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
- Choosing not to use changesets for code patches.
- Backtracking painfully when an error is made.
- Fretting at the beginning of a project what category a method will be packaged.
- Constantly checking to see if methods are still categorized correctly.
- Please note here that method categories are usual invisible to the coder. You can get into trouble without even knowing you are causing problems.
- Much more time consuming packaging concerns when trying to develop or repair code.
Back to New Modules