[squeak-dev] [ANN] MCInfoProxy

Bert Freudenberg bert at freudenbergs.de
Fri Aug 16 13:38:16 UTC 2013


On 2013-08-15, at 21:24, Chris Muller <asqueaker at gmail.com> wrote:

> [>> It happens to not find "XML-Parser-Alexandre_Bergel.20". No idea why it's
>>> trying to look for that. Not all merged versions are in trunk, by design.
>> 
>> The original MC documentation says ALL versions are intended to be contained
>> by repositories.  I have no idea what "design" you're talking about.
>> 
>> The idea is that versions are self-contained. When I merge two versions, I
>> only need to share and upload the result. That means that you will not find
>> that other version in your repo. But the merged version has all ancestry
>> data in it (you know that).
> 
> Did you notice that I uploaded ALL interim versions of
> Monticello-cmm.[552-557]?  Why would I do that when technically I only
> needed to upload 557?

We try to have a continuous "trunk" of versions in the trunk repository. We named it that way, even. But we do not store copies of all branches, because MC doesn't need them, and we don't need them. So versions that got merged into trunk do not need to be in trunk themselves, and for sure not their ancestors.

> Because MC functions depend on the ancestry model matching what's in
> the repositories.  Keeping all versions supports incremental
> development and rollback.  Besides that we should just maintain an MC
> model that is "whole" and operational rather than broken.  Are you
> concerned about disk space?

No, I am concerned about putting even more restrictions onto Monticello. We have gradually moved from a system with very few assumptions, over a period of non-enforced conventions, to a rigidly enforced one. Version names are an example of that. And now your adding a requirement to have an internet connection all the time because MC can unpredictably request an ancient version. I do not see that as a good idea.

>> I'm not aware of any current use of proxies in Squeak trunk.
> 
> Great then it's high time that Squeak has a working example of this
> well-known design pattern in the image.

Perhaps you can find a better example. And if not, then maybe it's not as essential as you think. Just because we *can* do something does not mean we *have* to. 

>>> I'd rather revert this whole thing, to be honest. If you're trying to
>>> build a minimal image for deploying an application you would be better off
>>> unloading MC altogether.
>> 
>> It's not just about smaller images.  It's about sustainability of the
>> ancestry.
>> 
>> But as soon as you use MC it needs the ancestry anyway.
> 
> Not all of it.  We're up to version 600+ of Morphic, when was the last
> time version 1 of Morphic was needed?  But we continue to carry that
> around, in and out of the system, forever.

It does not need to load these old versions, but it often needs to their version names, and sometimes the UUID, and having the commit message is useful too at times.

You're not doing anything about that need. You're just hiding it out of sight. That's not a solution.

>  It's a gradual decline, unsustainable.
> Levente and I are interested in addressing this.

A noble goal, and I agree we need to work on it, but you're not addressing it.

> (From the other note)
>> Well, I didn't complain right away ;)
> 
> < 24 hours dude.  ;)

I'm quick ;) I did test it, and thought about it.

>> It sounded like a neat idea at first,
>> but then I remembered that one of the things I really like about Monticello
>> is its clarity and simplicity. Everything is very concrete, whereas proxies
>> are very meta by nature.
> 
> We haven't lost clarity or simplicity.  That's the nice thing about
> this solution, it changes _nothing_ about the MC model.  It's very
> transient, all-in-memory.  There's no disaster scenario.

Wrong. Now just about anything you do can cause a file read or network access because MC is trying to materialize a proxy that shouldn't have been stubbed out in the first place. Before, each working copy could access its full ancestry data. That is a very serious change of behavior, in my book.

> I've use much more complicated MagmaProxies, millions of them,
> everyday for years.  They work.  The issue you experienced was
> predicted in my "Special Notes".  Please don't surrender yet.


Because in Magma there is a real need for proxies. In MC, there isn't.

- Bert -




More information about the Squeak-dev mailing list