Having autoMigrate turned off is why the update of Metacello failed ... that particular update changed the shape of an object that was actively used during the update, so without the migrate of the instance the new state was missing as well as the new methods which lead to the MNU ...
I do all of my testing with autoMigrate (for this reason) and in development I think it is the right setting to use since it duplicates the behavior of the Pharo environment ...
Automigrate is an option because automigration can be much slower to use in GemStone if there are a lot of instances to migrate or a bunch individual migrations ... sometimes a load that never finishes with autoMigrate on can finish with autoMigrate turned off.
With autoMigrate off you do have to worry about migrating any instances of old class versions yourself ...
I have started work on GsDeployer which is intended to supply some support for doing bulk migrates after a load, but because of problems like the Metacello problem (initialization that expects migrated instances is also problematic), I can't just apply the better algorithms across the board.
GsDeployer is in 1.0-beta.8.6 and i encourage you to take a look at it, expecially GsDeployer class>>cleanClassHistory, because it will clean up all of the old class histories and migrate any instances of the old class versions ...
I pushed 1.0-beta.8.6 a bit prematurely because you needed some of the bugfixes in it for Seaside 3.0.4
Dale
On Mar 5, 2011, at 10:58 PM, Johan Brichau wrote:
> That indeed fixes the problem.
>
> Yes, I have automigrate turned off.
> Should this be left on for updating?
>
> On 05 Mar 2011, at 22:17, Dale Henrichs wrote:
>
>> This is a problem that I saw quite awhile ago and personally haven't seen it for a long time ...
>>
>> Do you have autoMigrate turned off? I think this bug is related to a migration issue.
>>
>> `MetacelloGemStonePlatform initialize` will probably get you going again, but that shouldn't be necessary. I did a number of loads against a variety of initial starting versions and didn't see any problems.
>>
>> Dale
>>
>> On Mar 5, 2011, at 12:44 PM, Johan Brichau wrote:
>>
>>> Hi Dale,
>>>
>>> I'm doing this from the gemtools.
>>> After running the update for metacello, I get the same problem.
>>>
>>> Am I the only one having this problem?
>>>
>>> Johan
>>>
>>> On 05 Mar 2011, at 19:56, Dale Henrichs wrote:
>>>
>>>> You didn't mention, but are you doing this from topaz? I think Otto had this problem a while back and it was traced to not setting autoCommit to true during a topaz load ...
>>>>
>>>> Dale
>>>>
>>>> On Mar 4, 2011, at 11:45 PM, Johan Brichau wrote:
>>>>
>>>>> Hi Dale,
>>>>>
>>>>> Coming from a 1.0-beta.5 repository, when upgrading to 1.0-beta.6, I'm getting a DNU for #bypassGoferLoadUpdateCategories
>>>>> The repository is a fresh GemStone install extent which was only upgraded to 1.0-beta.5.
>>>>>
>>>>> I will now try starting from a fresh extent and going directly to 1.0-beta.6
>>>>>
>>>>> Johan
>>>>>
>>>>> On 04 Mar 2011, at 02:04, Dale Henrichs wrote:
>>>>>
>>>>>> Let me know if you have any trouble or questions,
>>>>>
>>>>
>>>
>>
>
Locked
