[squeak-dev] Trunk update continuity restored
leves at elte.hu
Thu Mar 17 17:49:58 UTC 2011
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
> 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.
> - Chris
>>> - Chris
More information about the Squeak-dev