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