upgrading monticello

Avi Bryant avi at beta4.com
Sun Jan 25 21:13:25 UTC 2004

I've just posted two new releases of Monticello to SM, revisions #86 
and #90.  Why two?  Because one of the bugs fixed in release 86 is 
triggered by release 90 - so if you're upgrading from an earlier 
version, you have to upgrade to 86 *first* (fixing the bug), and then 
upgrade to 90 (no longer triggering it).  If you try to upgrade 
directly from, eg, 69 to 90, you'll get an error halfway through the 
load and your image will be left in a horrible inconsistent state.  
Don't do this.  (Isn't self-hosting fun?)  Just loading 90 into a clean 
image should be fine, though.

I'm mostly pushing these releases out to get this annoying double 
upgrade out of the way, but they do provide some benefit:

- The aforementioned bug fix.  The bug had to do with updates that 
moved inst vars from subclasses up to superclasses (or, in some cases, 
vice versa).  These always have to be done by first removing the inst 
var from the old class and then adding it to the new one - if you don't 
do that, the ClassBuilder will complain about duplicate instance 
variables.  New versions of Monticello handle this in a pretty rough 
and ready way - any class or method definitions that have errors like 
this when being loaded will be deferred until everything else has been 
loaded, and the user will then be given the option to try loading the 
deferred definitions again.  The second time through, they should work.
- Some fixes from Ned, including a repository type that lets MC raid 
the SqueakMap cache.
- A lot of cleanup of the reader/writer classes.  The barely used .mcv 
format is no longer supported at all, and support for .mc files has 
been moved to MonticelloCVS, which is now the only thing that uses it.  
If you're one of the few using MonticelloCVS, make sure you upgrade it 
at the same time.
- Packages and their dependencies are now loaded as one atomic unit (as 
much as MC can load anything atomically), which means that you don't 
need to worry about ordering (you could, say, have a class in package A 
that subclassed one in package B and a class in package B that 
subclassed one in package A, and it should all load ok - not that I 
recommend this).

There's still *lots* more work to do on the dependency mechanism, 


More information about the Squeak-dev mailing list