Monticello and live systems (was Re: 1 day left...)
Todd Blanchard
tblanchard at mac.com
Sun Feb 26 07:35:21 UTC 2006
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.
>
More information about the Squeak-dev
mailing list
|