MC downloading unexpected .mcz files

Hi,

after updating my clean trunk developement image, and evaluating
"Smalltalk cleanUp", MC downloaded all missing .mcz files from the
Trunk repository, when I was trying to open my package cache.
I understand that some version info is necessary for opening a repository
browser, but downloading versions from other repositories - especially
complete .mcz files, when the corresponding .mcd files are available - is
something that I would never expect. So I think the recent MC changes
have broken something there.


Levente

It might be the recent change to MCWorkingCopy class>>#cleanUp:.

Smalltalk cleanUp should clean up, eh?


On Mon, Sep 23, 2013 at 4:47 PM, Levente Uzonyi <[hidden email]> wrote:

On Mon, 23 Sep 2013, Chris Muller wrote:

> It might be the recent change to MCWorkingCopy class>>#cleanUp:.
>
> Smalltalk cleanUp should clean up, eh?
>

#cleanUp is mainly for flush caches.

The .mcd files contain the full ancestry info, so downloading .mczs is
just wrong.
And I don't see why the full ancestry is loaded, when only the last
version info will be used to display the data.


Levente

On 2013-09-24, at 02:49, Chris Muller <[hidden email]> wrote:

> It might be the recent change to MCWorkingCopy class>>#cleanUp:.
>
> Smalltalk cleanUp should clean up, eh?


It should clean up caches that can be recomputed when needed. Removing essential information from the image is not part of that.

- Bert -

>> Smalltalk cleanUp should clean up, eh?
>
> It should clean up caches that can be recomputed when needed. Removing essential information from the image is not part of that.

My understanding is that depends on whether the aggressive option is
chosen.  According to Levente, aggressive cleaning might clean to some
unrecoverable state.  But with non-aggressive, it can be recomputed to
its prior, exact state, but with no contracts with regard to
performance.

Stubbing the ancestry falls into the latter, and it shouldn't take any
longer than opening one mcz file per package, at most.

However, I can see that my last fix to MCInfoProxy is causing an
endless recursion because I used breadthFirstAncestorsDo: in the
materialization process, which wants to put the Proxy/Info into a Set,
which requires materialization for its #hash.  It doesn't need to,
since its hash is simply the hash of its info's id, which it already
has.

I'll submit a fix.

On 2013-09-24, at 17:57, Bert Freudenberg <[hidden email]> wrote:

> On 2013-09-24, at 02:49, Chris Muller <[hidden email]> wrote:
>
>> It might be the recent change to MCWorkingCopy class>>#cleanUp:.
>>
>> Smalltalk cleanUp should clean up, eh?
>
> It should clean up caches that can be recomputed when needed. Removing essential information from the image is not part of that.
>
> - Bert -


Also interesting: after stubbing we end up with even more instances than before:

"before"
MCVersionInfo instanceCount  10515
"after opening cache repo"
MCVersionInfo instanceCount 10515
"after flushing 2 versions"
MCVersionInfo instanceCount  9300
"after stubbing"
MCVersionInfo instanceCount  3078
"after opening cache repo again"
MCVersionInfo instanceCount 10833


- Bert -