On 09-04-2014, at 1:43 PM, Chris Muller <ma.chris.m at gmail.com> wrote:

>>> The idea was to make that "10" a preference value, and to change the
>>> tools like "History" to respect the preference.  Because usually we
>>> don't need to look back more than 10 versions, but when we did it'd
>>> retrieve it automatically, dynamically, silently.
>> 
>> Nice idea in general though I'm not often a fan of the 'silent' bit. And especially not a fan of the 'unasked massive file loading' aspect.
> Replacing the ancestry with a stub that can fetch the rest of the
> history is an excellent idea but how about making it ask the user
> first? It may well be inconvenient or even impossible to fetch the
> files, for example. I can see that there might be places where
> allowing the user to prevent loading something might cause other
> problems, but surely catching those cases would be preferable to
> getting the error from a failed network probe?
> 
> You want to have a 100% guaranteed interruption prompt box to avoid a
> _possible_ network error box 1% of the time?

Given an ancestry stubbed by the current proxy based mechanism, yes I’d like to be warned if something causes the proxies to trigger and want to fetch stuff from the net. Errors may be rare but the *time* it takes can be considerable. I have fairly fast net access at home but lots of people don’t. I may simply want to stop the operation because it was triggered by something not really relevant - like accidentally doing so as part of chasing pointers. It isn’t only network failures.

> 
> What is the scenario that has you wanting to stub ancestry and then
> get it back in the first place?  In my world, the only use-case I can
> think for that is "debugging in production".  I'm in one of my
> production images which had been previously "shrunk", and sometimes
> viewing change-history is a useful part of debugging.  But if I'm in
> the production image then I've got network access so, no problem..?
> 
Not all production images have network access. So there needs to be a way to handle the attempt cleanly.

My scenario is simply an attempt to find out what is occupying so much space in my image and attempt to remove or at least reduce them. Your mechanism for getting rid of a lot of MC version stuff is useful but the proxies cause later issues. 

In any sort of production image I suggest that we’d be better off with a way to just remove the MC data completely, and thus avoid the entire proxy discussion. Given a default image distributed with the accent of developer usage -  a perfectly reasonable approach - it would be nice to have easily findable, effective tools to remove as much as possible and practical that can be dumped. 2-3Mb of ancestry data could be argued to have value for developers but not really in production.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- During evolution his ancestors were in the control group.