[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)

[Dale Henrichs via Glass]

On 8/26/15 11:44 PM, Otto Behrens via Glass wrote:
> This may help you when using changeNameTo:, so, this is what we do
> every time after loading code with Metacello:
>
> | gofer |
> gofer := Gofer it.
> gofer disablePackageCache.
> gofer repository: self localWonkaCodeRepository.
> allPackageNames doWithIndex: [ :packageName :index |
>    (MCWorkingCopy registry values anySatisfy: [ :workingCopy |
> workingCopy package name asSymbol == packageName asSymbol ])
>      ifTrue: [ gofer package: packageName ] ].
> gofer load
>
> Where allPackageNames is:
> ((MetacelloMCVersionSpecLoader on: <config class> latestVersion spec)
> required: {aGroupName};
> resolvePackageNames;
> packages) values
>
>
Well obviously, this should not be necessary - and I understand that 
when you are in the heat of development you have no time to characterize 
problems:)

I use Metacello all of the time in GemStone (not Pharo) and I don't find 
it necessary reload all of the packages ... but that does not mean you 
don't have good reasons for doing this:)

I _will_ ask on of my standard questions - are you using the latest 
version of Metacello and glassdb from GitHub?

Now that we've got this out of the way, I do know that there are certain 
sets of refactorings via Monticello loads that can cause problems for 
GLASS/GsDevKit  (moving instance variables up the hierarchy is the main 
example) ... turning autoMigration can reduce some of the problems 
(GsDeployer class>>bulkMigrate: turns off automigration) - with 
autoMigration turned off, subclass recompilation is suspended, but I 
guess there could be traps there as well ... I need to have a better set 
of test cases and I need to be aware of these problems and I need to 
find the time to address them:)

I am surprised that you have problems "everytime you load using 
Metacello" - if you are doing this in self defense then I understand, 
but if you are truly seeing issues every time, I would like to fix that 
pretty quickly ...

The standard Monticello package loader used by GemStone is pretty old 
and pretty simplistic and I suppose we could invent a better loader, but 
I would need some good examples of the refactorings that cause problems 
so we can set out with a set of the hard problems in our test suite ...

Dale