[squeak-dev] Monticello 1.6 features (was: Monticello/MCM tricks)

Matthew Fulmer tapplek at gmail.com
Sat Jul 4 20:17:39 UTC 2009


On Sat, Jul 04, 2009 at 12:18:11PM -0700, Andreas Raab wrote:
> Ken Causey wrote:
> > Oh good, I have to admit I wasn't absolutely sure there wasn't something
> > more I needed to do.
> 
> If the change is local to a single package there is not much you need to 
> do. Monticello is reasonable in this case and the updater will just load 
> the version of the package. Where it gets nasty is:
> 
> * When you rename classes (this may have been addressed in one of the 
> later MC versions?) as Monticello will delete the old class mercilessly, 
> leaving all the instances in the dust

No Monticello version deals correctly with this case.
DeltaStreams does, however. SystemEditor can handle this case,
but the Monticello snapshot mechanism simply looks at the state
of the system and stores no metadata about what changed between
versions

> * When you move classes between packages where you need to issue an 
> update.mcm so that you have the destination package before the source 
> package so that the class doesn't get deleted in the middle (of course, 
> some of the time the update.mcm will be in the right order and you get 
> lucky ;-)

With MC1.6, if the packages are loaded together, it should
always work, but I don't think I ever tested this. MCM's
probably load packages together; I've never looked at them.

> * When you have system methods that are modified during load and rely on 
> new methods in the package. This is by far the biggest issue (and a 
> problem even with Change Sets). For example, 
> http://bugs.squeak.org/view.php?id=6535 contains a change to 
> OrderedCollection>>copyFrom:to: which utilizes postCopyFrom:to: that is 
> defined in the same place. In change sets you can at least manually 
> reorder the methods. Monticello does it unpredictably so it may work for 
> one person and not for another (I wish MC would load methods in a 
> well-defined order).

This is never a problem in MC1.6, period. In MC1.6, the new code is
never run until the entire package is loaded; during the load,
the system is static; only after the load is the new code. MC1.6
is able to move instance variables and rename core Monticello
methods during the load, with never a hiccup.

MC1.5 is an improved version of Monticello with a number of bug
fixes and improvements:
- compatibility with both the 3.8 and the 3.9 format of .mcz
  files.
- Better handling of out-of-order loading: loading extensions
  and subclasses of not-yet-loaded classes is delayed until the
  missing class is loaded.
- More versatile package naming; branching and real-world version
  numbers are supported: Monticello-mtf.experimental.1.5.147
- A new dual changes tool, that can quickly compare arbitrary
  versions without loading
- A recent history of commit messages, so you can reuse them
  easily (merged from Pharo)
- Completely rewritten image scanning code, resulting in about
  10x faster snapshotting.
- And some others.

MC1.6 is identical to MC1.5, except that it has a vastly smarter
loader, which first compiles all classes and methods outside the
live class hierarchy, then migrates all methods, classes, and
instances during a single mass-become primitive, making it truly
atomic, and up to 6x faster at loading.

There are currently 2 outstanding bugs in MC1.6:
- No traits support in SystemEditor
  - SystemEditor is the engine that manages the compilation and
    migration of the temporary classes and methods outside the
    class hierarchy. It needs to know a lot about the internal
    structure of Classes to do this, but it was never taught
    about Traits, and I have not yet finished this coding.
- Obsolete classes are sometimes left behind

And one bug in both MC1.5 and 1.6:
- Class initialization methods are run in a different order than
  previous Monticellos.
  - This causes problems when loading some packages from
    Universes, although I forget which packages.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/



More information about the Squeak-dev mailing list