On Sat, 2009-07-04 at 12:18 -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
> 
> * 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 ;-)

This change is in fact all about packages, moving code from one package
to another.  But the move in this case happens to be to a package now
outside of trunk so only the packages from which code disappeared remain
and need to be loaded.  Should be OK I think.

> * 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).
> 
> To deal with this, you need to make a separate MC package version with 
> *just* the prerequisite method (in this case postCopyFrom:to:) and issue 
> an update.mcm for that precise version of the package; this will ensure 
> the updater loads that precise version of the package before going on to 
> load the version of the method that utilizes it. When there's a lot of 
> dependencies this is obviously not a very rewarding process...
> 
> Cheers,
>    - Andreas
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090704/9d6268e4/attachment.pgp