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.