On 14.11.2014, at 16:17, Chris Muller <asqueaker at gmail.com> wrote:

> On Thu, Nov 13, 2014 at 8:15 PM, tim Rowledge <tim at rowledge.org> wrote:
>> Even after use of doits such as         MCFileBasedRepository flushAllCaches & MCDefinition clearInstances I have 9500 MCVersionInfo and similar numbers of other MC related objects in my image. And 990 SMAccounts? 800 SMPackage? 13000 UUIDs? That all seems a bit excessive somehow.
>> 
>> I know there was a conversation about chopping at least some of the MC stuff out (which I think is where the flushAllCaches came from) but it seems there is an awful lot left that could be removed as part of making a deployment image.
> 
> There is also 'flush cached versions and ancestry' on the MC
> repository menu next to 'flush all caches', which goes back just 10
> versions ago and trims the MCInfoProxy tree from there.  Space
> consumed by 95% of your MCInfoProxy instances is recovered, without
> actually losing any data.  The proxy will reload them dynamically if
> asked (e.g., by you clicking on History button of a package).
> 
> I know Bert doesn't like it, but Smalltalk is an environment that's
> supposed to support "debugging in production".  There is a common
> usage case in MC that causes the Proxy's to be prematurely agitated
> unnecessarily, resulting in a delay while they're re-loaded, which
> nobody liked (understandably).  I never had time to investigate that
> but if you do, that'd be really great.
> 
> The thing I don't care for about Berts solution is the hindrance to
> debugging in production.  Invariably it will happen by necessity.
> After making a code-fix, someone might be tempted to re-add the
> WorkingCopy and then save the package -- losing all the ancestry!

Stripping and deployment was never discussed when you introduced this, and enabled it, by default, for all developers. That was one reason I was opposed.

For a deployed image the stubbed ancestry might be much better indeed - and for that use case I wouldn't even retain 10 levels of history, but strip it down to a single version info per package. Just the bare info needed to pull in the full ancestry. (I also would make re-instating the full version hierarchy an explicit action rather than a side effect, but we had that discussion already).

- Bert -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141114/6b7e7813/smime.bin