Todd Blanchard wrote:
> They seem to be good at different things.  Monticello is all about 
> maintaining packages and in my view is a much *SAFER* mechanism for 
> loading in new functionality (packaged code) than changesets.  For one 
> thing, it does a good job of preflighting the changes and if its going 
> to have issues it will tell you and you can bail on it or it will help 
> you get to the desired final state.  So as a librarian - MC is DA BOMB.

Agreed. As a programmer who is trying to build a system from first 
principles MC is vastly superior to change sets.

> However, when it comes to maintaining modules and packages (chunks of 
> capability that are a "THING"), I feel that changesets are AWFUL, crap 
> out more often than not because my image isn't in the starting state the 
> changeset was based on and changeset loading doesn't preflight well.  If 
> it fails I have an image in an indeterminate state and have to quit and 
> relaunch to get back the last saved (and sane) state.  I can't begin to 
> count the number of times I've set out to load a .sar file and had it 
> crap out because something in my image wasn't in the state that file 
> expected.

It's a funny set of tradeoffs since I could counter this with pointing 
out that it is now pretty much impossible for anybody to keep up-to-date 
with the latest alphas. All of your changes will be wiped out by loading 
that latest one-line fix which means you have to rebuild your image from 
first principles whenever anything changes (e.g., all the freaking time 
;-) I wonder how many people these days actively track 3.9alpha (if at 
all) and how many of those do *any* of their own work in these images. 
Personally, I stopped doing it after a few more important changes got 
wiped clean, where (in the past) I've typically used the latest-greatest 
to make sure  things get tested properly.

> As an exercise, try grabbing a 3.6 basic image and see if, using old 
> .sar's on SqueakMap, you can get an image configured with Kom, Seaside, 
> Postgres, and GLORP and let me know how many tries it takes you.

Yup. Agreed. And countered by: Try grabbing a 3.8 image and get it to 
3.9 using Monticello alone ;-) And then use the update stream and see it 
fail, too, because there are apparently some dependencies which need to 
be carefully observed and have been condensed by Monticello in the wrong 
form. [Disclaimer: Haven't tested this very recently; I tried it a 
couple of weeks ago and got totally hosed].

> This is because changesets don't capture the expected initial and final 
> state - only the transitions - and that is seldom enough when you're 
> trying to work in a team and build a single "thing".
> 
> We really need a tool that knows both.

Agreed as well.

Cheers,
   - Andreas