[Glass] Upgrade GS 2.4 -> GS 3.1 when GLASS, Seaside etc. versions have already diverged

[Pieter Nagel]

I managed to run through upgradeSeasideImage without any (obvious)
errors with the advice given here.

But now I can't load Seaside30. As part of it, a class-side #initialize
is triggered that tries to set an #exceptionHandler on the application
configuration, but Seaside moans that the specific attribute does not
exist.

My main problem is that I cannot debug what is going on. When I log in
to the repository via topaz afterwards, all the methods that I saw in
the stack trace are just gone. I went so far as to compare the oops of
the classes in the stacktrace to the oops of the classes in the
repository, and they're all the same. I also tried to wrap the loading
code in an "[...] ensure: [System commitTransaction]" block, to no
avail.

Does metacello have an error-handler that unloads all methods it loaded
on error? (Remember, the state that upgradeSeasideImage left the
repository in is that it deleted all methods on all classes in
UserGlobals, so any rollback would leave the repository in that state).

Alternatively, is there any way to tell Metacello to not call
#initialize on classes? I suspect that what's happening is that the
missing methods that upgradeSeasideImage deleted breaks some descriptors
of some Seaside classes, which get queried (and cached on the
#description instvar) at a point before the source code is reloaded, and
thus Seaside does not relaise that #exceptionHandler is a valid
configuration. If this is the case, I can use Metacello to load the code
twice, and only enable #initialize the second time.


-- 
Pieter Nagel