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

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.

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

 - Chris


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