Unfortunately, I don't think the config can be fixed.  It's
chicken-egg problem; and both parts are the running parts involved in
the update process itself.

On Tue, Mar 15, 2011 at 9:22 PM, Chris Muller <asqueaker at gmail.com> wrote:
> Yikes, my apologies.  I will see if I can fix the configurations.
>
> In the meantime, if you just want to move forward with trunk again,
> just load the latest Monticello manually from the trunk, then
> MonticelloConfigurations.  You can then update from the trunk
> normally.
>
>  - Chris
>
>
> On Tue, Mar 15, 2011 at 5:31 PM, Levente Uzonyi <leves at elte.hu> wrote:
>> On Tue, 15 Mar 2011, Eliot Miranda wrote:
>>
>>> Hi Levente,
>>>
>>>    just when I wanted to update to trunk ;)  Is there a work-around, e.g.
>>> where one can prevent a particular set of packages from being updated?
>>
>> There are some workarounds, like commenting the following two lines at the
>> end of MCMcmUpdater class >> #updateFromRepositories:
>>
>>        config updateFromRepositories.
>>        config upgrade.
>>
>> Or disabling the update of Monticello and MonticelloConfigurations by
>> evaluating the following before updating:
>>
>> #('Monticello' 'MonticelloConfigurations') do: [ :each |
>>        MCMcmUpdater disableUpdatesOfPackage: each ].
>>
>>
>> Levente
>>
>>>
>>> On Tue, Mar 15, 2011 at 12:56 PM, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>>> The update process is broken, because Monticello is updated before
>>>> MonticelloConfigurations. When Monticello-cmm.438 is loaded,
>>>> MonticelloConfigurations is still at ul.84.
>>>> MCConfiguration >> #versionNamed:for:from: tries to send
>>>> #versionFromFileNamed: to an MCHttpRepository, but that method is not
>>>> there
>>>> anymore.
>>>>
>>>>
>>>> Levente
>>>>
>>>> snip
>>>>
>>>>
>>>
>>
>>
>