On Fri, Apr 7, 2017 at 2:13 PM, Milan Vavra via Squeak-dev
<squeak-dev at lists.squeakfoundation.org> wrote:
> Chris Muller wrote:
>> I haven't looked at it, but would like to ask if you've tested when
>> you have multiple .mcd's in succession?  Like, if you have,
>>
>>     Kernel-cmm.100.mcz
>>     Kernel-cmm.101.mcd
>>     Kernel-cmm.102.mcd
>>
>> Does 102 need to have ancestry at least back to 101 (or, 100?) still
>> stored?
>>
> Assuming we have
>   Kernel-cmm.100.mcz
>   Kernel-cmm.101(cmm.100).mcd
>   Kernel-cmm.102(cmm.101).mcd
> then yes, 102 needs to have ancestry going back to 101. But no further.
> No need to go beyond 101. Ancestry from 101 onward can be trimmed.
> So when writing
>   Kernel-cmm.102(cmm.101).mcd
> ancestry of Kernel-cmm.101 can be trimmed. In the file we are saving, not
> in the system, that's why we need a #veryDeepCopy of the ancestry before
> we trim it.

So it reduces redundancy and disk utilization, with the trade-off
being that it must re-open the original .mcz in order to get that
ancestry back into memory.

That read should be done eagerly, otherwise the system would interpret
the empty ancestry as simply no ancestry.

> And when reading
>   Kernel-cmm.102(cmm.101).mcd
> ancestry of Kernel-cmm.101 can be re-attached so that Kernel-cmm.102's
> version info looks the same as it did when we were writting the
> Kernel-cmm.102(cmm.101).mcd before the trimming.

You said, "can be", but I think it should do it eagerly to avoid
unintended consequences.  If we don't open the original .mcz eagerly,
then I think we would need to terminate the ancestry with some kind of
"reference stub" instead of an empty Array.