Chris Muller 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 is correct. See below.

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

Good point.

The original mcz is being opened. Albeit indirectly and behind the
scenes.

The code
MCRepositoryGroup default versionWithInfo: baseInfo
basically does that.

What it does is ask the system: 'in any of the repositories known to you,
look for a version with this UUID and return it to me'.

We then attach its ancestors to our newly read version info at points where
the base version info is referenced.

>> 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.
>

I said "can be" but what I really meant is "is being re-attached".


Best Regards,

Milan Vavra




--
View this message in context: http://forum.world.st/The-Inbox-Monticello-mva-667-mcz-tp4941466p4941583.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.