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