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.

For example, when you rename class Foo into Bar Monticello is utterly 
unable to recognize this and will happily convert all of your existing 
instances into ObsoleteFoo's. That's deadly in a live system. Similarly, 
if you change the shape of a class multiple times and require 
intermediate steps to update existing instances, Monticello will often 
(by combining all the changes into a single one) wreck utter havoc upon 
the system. Or take "reclassifications" (e.g., moving methods between 
packages) - unless you take great care, methods may simply be removed. 
Or doIts - many a time we need to do one-time fix-ups and those may only 
be appropriate at a single point in the evolution of the live system 
(e.g., cannot be handled in an initialize method). Monticello has no 
good way of dealing with that. And I won't even go into dependencies 
(e.g., you need change A before change B before change C) since this is 
only partly a Monticello issue (but MC does make it hard to serialize 
changes properly).

All of these have caused me lots of trouble and none of them has much to 
do with scale. I think that the key issue is that because of the 
snapshot approach that Monticello uses, it simply lacks information. 
Information like whether class Foo has been renamed to Bar (contrary to 
adding Bar and removing Foo), information like whether a method has been 
moved out of a package vs. it being removed from the system. And since 
it looses the intent of the change it needs to guess later on and it 
just guesses wrong as often as it guesses right.

Interestingly, this information *is* available in change sets which is 
really at the root of my claim that change sets are better suited to 
maintain live systems. Speed, scale, cross-cutting changes are (albeit 
important) secondary to these more fundamental issues.

> You also mentioned that "it doesn't work the right way for incremental 
> migrations." The strategy Monticello uses it to compare the version 
> being loaded with what is already in the image and make only the 
> necessary changes. Are you finding that this is the wrong strategy for 
> your needs? Or perhaps that Monticello isn't executing that strategy well?

It's really both. If I rename class Morph to FooMorph I cannot afford 
Monticello to nuke all Morphs. If I move Object>>size between packages I 
cannot afford Monticello to nuke that method just because I load an 
updated version of the package that contained #size before (even if I 
load the other package later chances are that my system has long died 
since then).

> I also agree that a different approach is required. I don't think the 
> way ancestry information is modelled in Monticello will allow for much 
> more optimization, so we'll have to change something fundamental. I have 
> some ideas about the direction to take, but I'd be interested in hearing 
> what you think would be useful.

Well, it's a hard problem. One idea might be to actually record the 
changes and use that in cases where it is relevant (e.g., remove vs. 
classification etc). I'm certain there are issues with that approach but 
it might be worthwhile to think about.

Cheers,
   - Andreas