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.

Changesets seem better for system level stuff that involves lots of  
refactoring.  As an example, I've been trying to consolidate all of  
the code that knows something about URL's and Http into a coherent  
package.   Its scattered all over the image in half a dozen packages  
so this change will involve many package name changes, class name  
changes, moving methods, etc.  Monticello seems to act on packages,  
so to capture this work and get it applied, I think a changeset is a  
better tool.

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.

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.

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.

-Todd Blanchard

On Feb 25, 2006, at 11:08 PM, Andreas Raab wrote:

> Colin Putney wrote:
>> First, let me mention that Monticello was designed with  
>> maintaining live system in mind. I think where it falls down is  
>> with scale.
>
> Actually, I think there are some very fundamental issues when using  
> Monticello in a live system, e.g., a system which has live  
> instances of the classes being changed. The most important ones I  
> can think about (which have nothing to do with scale) are renaming  
> classes and series of class migrations.
>