Am 20.05.2006 um 20:48 schrieb Colin Putney:
>> I believe that the management of the code of Squeak in tool  
>> supported packages is a critical component of any solution - this  
>> is the only way to keep the boundaries up to date. So the  
>> existance of MC exists makes this task somewhat feasible, but  
>> there have been various problems with its use to manage the whole  
>> image.
>>
>> - Performance (loading updates to the image using MC is much  
>> slower than loading changesets).
>
> There are several aspects to this, but the primary one is that MC  
> doesn't version code so much as packages. Because of the dependency  
> issues in Squeak, packages are either really big, or a "small"  
> change touches a lot of them. Either way, it means moving a lot  
> more data and doing more work to update image than what is required  
> for a change set. In practice, that makes it too slow everyday  
> workflow.
>
> MC2 actually versions code, so it has a lot more flexibility. It  
> would be possible, for example, to create an update stream of  
> "versioned changesets" that wouldn't carry too much overhead  
> compared to the classical update stream.

Well ... the most severe performance-related MC problems in an  
upstream-like scenario are actually solved. Provided you have an  
unmodified package in the image, you can update to a later version of  
that package simply by applying the changes in a differential MC  
package (MCD), which is pretty much equivalent in performance to  
loading a changeset. It avoids the really slow parts of loading a  
package, which consist mainly of building a changeset to modify the  
in-image snapshot to the version-to-be-loaded snapshot. We simply  
move that work to the server-side, I patched SqueakSource to provide  
an MCD going from any older version to the wanted version on request.

I'm still unsure why this has gone largely unnoticed, maybe because  
the technique to actually request an MCD instead of an MCZ from the  
server is only used by MCConfigurations, not plain MC.

>> - System changes (like introducing Traits) require going through  
>> various intermediate stages, but MC itself only model merging the  
>> code in order to reach the final stage to be loaded.
>
> Yes. It's surprising how little this has affected at the higher  
> levels of the system. (For example, MC can usually update itself  
> without problems.) To manage all of Squeak, though, I don't think  
> we'll be able to escape having some kind of update stream based on  
> filing in arbitrary code.

That's what we did with Tweak, it uses a classic update stream that  
usually just loads new MC versions (via config maps, so we have a  
changeset-like performance), but it can include arbitrary code for  
trickier changes, too.

> MC2 can help with this part as well. It can do atomic updates to  
> the image, so the cases that require carefully orchestrated  
> migrations should be very rare. I'm imagining only issuing updates  
> every year or two, and having stuff stay pretty compatible in  
> between updates.

Sounds very nice :)

However, I'm not sure we only have a tools problem. The stuff I  
mentioned above is readily available for some time now, so if people  
wanted, they could have used it. With MC2 we'll get even better and  
faster tools (right? ;-), but it will still be a problem of people  
stepping up to actually use them for advancing Squeak. I'm no  
exception here, apart from the packages I maintain, I just post the  
occasional fix to Mantis as a changeset and let whoever else take  
over, which until now usually was Marcus alone. So apart from better  
tool support we still need to find away to let people contribute more  
easily.

- Bert -