As far as I can tell, there are several fundamental things that  
Squeak (and Smalltalk) have not yet gotten right, but could. Among  
these are namespaces and version dependencies. (One example of the  
latter is that resource A uses B and C, but B uses version 1 of D,  
and C uses version 2 of D.)

Until these are confronted, I feel that Monticello (and change sets)  
will always be "half a loaf:"  they do what they do - often well -  
but don't address the fundamental issues brought to the fore by  
evolution of large, complex, independently developed yet interrelated  
systems.

-H

On Feb 25, 2006, at 7:05 PM, Colin Putney wrote:

>
> On Feb 25, 2006, at 4:54 AM, Andreas Raab wrote:
>
>> I think a discussion about how Monticello fits a working style  
>> that can be used to maintain a live system is overdue by now.  
>> Having been there, having seen the immense pain Monticello  
>> inflicts on both sides of the maintenance chain (not only is it a  
>> pain for the person doing the maintenance, it is also a pain for  
>> the person on the receiving end of the maintenance) I think we can  
>> say with some certainty that Monticello fails in this regard and  
>> that another approach is needed.
>
> Good idea.
>
> First, let me mention that Monticello was designed with maintaining  
> live system in mind. I think where it falls down is with scale. If  
> you're working on a system with lots of packages, packages  
> containing lots of code, packages with lots of ancestry, or with  
> changes cutting across lots of packages, it does get slow. Also, we  
> try to deal with some aspects of this slowness with caching, which  
> can take up a lot of memory. So, yes speed is a problem for  
> anything but small projects.
>
> 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?
>
> 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.
>
> Colin
>