On Sep 14, 2004, at 10:19 AM, Bert Freudenberg wrote:

>> We actually discussed this a bit earlier (although no one summarized 
>> the reasons as well as you did here) and generally agreed that 
>> Monticello should go in 3.8.  It's actually in the plan for 3.8:
>>
>> http://minnow.cc.gatech.edu/squeak/3832
>
> I assume you're speaking about the full image, right? We agreed 
> earlier on that no packaging system should go into the base image, but 
> only the infrastructure necessary to build one, in particular 
> PackageInfo. I agree it should make it into the full image which has 
> all sorts of developer tools.

We've agreed various things at various times, mostly because "agreeing" 
in this case usually means that a few people say "yes, sounds good" and 
those who object don't notice the thread or choose not to argue.

 From my point of view, the crucial issue is not what goes into the 
image so much as how we manage the update stream.  People can always 
install Monticello from SqueakMap if they want to, and actually SM now 
does a pretty good job of installing it automatically when it's needed. 
  But a lot of our process revolves around the update stream, and given 
that more and more core packages are being managed by Monticello 
(Markus is using it for his Compiler work and for SUnit, for example), 
there needs to be *some* kind of integration between them.

I can think of two ways this can happen: one would be to allow .mcz or 
.mcd files to be put into the update stream directly, and handle them 
by using Monticello's automatic merging to update the image but 
preserve any local changes.  This would make the user aware of any 
conflicts, and would correctly preserve the ancestry of any changes 
they made correctly, so that if the user then publishes their changes 
they can be correctly merged into other people's images as well.  
However, it would obviously require that Monticello be included at a 
fairly basic level, because the update stream wouldn't work without it.

The second option would be for me to set up some mechanism where you 
can "commit" MC versions to the update stream, where a diff is 
automatically done against the last version of the same package that 
went in, a changeset automatically produced, and this is what actually 
goes out to people's images.  Although this doesn't require MC to be in 
the base image, it means that if people *do* have MC loaded, then their 
images are going to get somewhat screwed up, since they're making 
changes to packages managed by MC without properly adjusting the MC 
ancestry metadata.

I would prefer the first, but if there's opposition to that, then let's 
decide soon that we're not going to do it, so that at least I can 
implement the second and make it available.

Avi