[squeak-dev] Trunk update continuity restored

Chris Muller asqueaker at gmail.com
Fri Mar 18 01:22:43 UTC 2011


> Is it possible to upload a new version that contains the merge and use that
> in the configuration maps?

I'm not in front of it at the moment but, from my memory of late last-night:

update-cmm.179 is the one that "jumps forward" the version of MC and
MC-Configurations via the TrunkUpdate script.  But, because the call
to the old, now-deleted method is still on the execution stack, I also
recompiled the method from within that same script.  This, of course,
leaves the Monticello package dirty and what leads to the inevitable
merge-conflict once the _next_ update loads an even-newer version of
Monticello.

Hmm!!!!  Maybe two versions both trying to delete the same method
should not be regarded as a conflict!

But it's too late for that now, the only tool we have to solve this
problem (assuming someone cares enough to solve it, I don't) is the
MCConfiguration's ability to process that TrunkScript.

That's what I was doing last night, making updates to the TrunkScript
preamble and changing update-cmm.179 to refer to the new version.

Now, just as I'm typing here, am wondering whether the method being
deleted couldn't be _moved_ to TrunkScript package (as an extension)
or whether that'd result in a similar merge conflict..  Oh well..

>>> Also the mcd files don't appear in the package cache (like
>>> Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like
>>> Tests-cmm.177.mcz.
>>
>> I didn't get to this one.  I'm so behind now, I'll have to look at
>> this in a few days.  mcd's are just an optimization for FileBased
>> repositories which cannot support a fully-canonicalized model; things
>> appear to at least be working for now.
>
> Yes, it's just and optimization which saves bandwidth and processing time on
> both client and server side.

Sure, I totally agree.  I'm just wondering whether anything I did
would have any effect on this.

I just tried setting the "store diffs" option on that repository
(package-cache), updated from the trunk, and I had new mcd's in there
and no mcz's...  Or are you referring to something else?

 - Chris



>
>
> Levente
>
>>
>> - Chris
>>
>>
>>>
>>>
>>> Levente
>>>
>>>>
>>>> - Chris
>>>>
>>>>
>>>
>>>
>>
>
>



On Thu, Mar 17, 2011 at 12:49 PM, Levente Uzonyi <leves at elte.hu> wrote:
> On Wed, 16 Mar 2011, Chris Muller wrote:
>
>>> But the update process is still broken. If you update your image and
>>> there's
>>> a new configuration map defined, then packages newer than those defined
>>> in
>>> the last configuration map are not loaded. You have to update your image
>>> again to make that happen.
>>
>> Dang it.  After an entire day of working on it, I managed to get this
>> fixed.
>>
>> However, there is, once again, no way out of a manual intervention.
>> Here's what's happening:
>>
>> MCConfigurations package sends #versionFromFileNamed: to a
>> MCRepository (in the Monticello package).  This is a method that must
>> eventually be removed.
>>
>> However, it does this *inside the loop* at the bottom of MCMcmUpdater
>> class>>#updateFromRepositories:, so the call to that is on the stack
>> for the entire update process.  How, then, would it be possible to
>> load a package which includes the removal of that method without
>> disrupting the update process?
>>
>> I've put, like, 100 hours total into this MC upgrade, and the code is
>> way better than it was.  But because this is part of our update
>> process itself, there is a hiccup in our update.  You have to *Reject*
>> the changes when the Merge browser is presented so that THAT update
>> process can finish out..  After that, it's fine.
>
> Is it possible to upload a new version that contains the merge and use that
> in the configuration maps?
>
>>
>> This "problem" will be in "oblivion" in 6 months..  Anyone who cares
>> enough about to see if there is a way to get around this is more than
>> welcome.  I've put as much time as I can into it.
>
> Thanks for your time and the fixes. I know how frustrating it is when you've
> something that's ready, but doesn't integrate easily.
>
>>
>>> Also the mcd files don't appear in the package cache (like
>>> Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like
>>> Tests-cmm.177.mcz.
>>
>> I didn't get to this one.  I'm so behind now, I'll have to look at
>> this in a few days.  mcd's are just an optimization for FileBased
>> repositories which cannot support a fully-canonicalized model; things
>> appear to at least be working for now.
>
> Yes, it's just and optimization which saves bandwidth and processing time on
> both client and server side.
>
>
> Levente
>
>>
>> - Chris
>>
>>
>>>
>>>
>>> Levente
>>>
>>>>
>>>> - Chris
>>>>
>>>>
>>>
>>>
>>
>
>



More information about the Squeak-dev mailing list