On 11 March 2013 22:17, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2013/3/11 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>> 2013/3/11 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> 2013/3/11 Frank Shearar <frank.shearar at gmail.com>:
>>>> On 11 March 2013 21:58, Nicolas Cellier
>>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>> 2013/3/11 Frank Shearar <frank.shearar at gmail.com>:
>>>>>> On 11 March 2013 21:24, Nicolas Cellier
>>>>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>>>> It seems that this change created some obsolete instances because
>>>>>>> SmallLandColorThemes were deleted.
>>>>>>> When you perform such a change, you must prepare an update with
>>>>>>> SmallLand-ColorTheme packaged placed above System
>>>>>>> I will try and fix (update-cwp.225 to update-cwp.227) to correct future build...
>>>>>>
>>>>>> Ah. My apologies for adding to your workload. I thought that since it
>>>>>> was a "simple" move of classes from one package to another that it
>>>>>> would be fine. I forgot that these commits are _migrations_ from one
>>>>>> state to another (just like a database migration), and so require
>>>>>> constant thinking about imperative effects like these.
>>>>>>
>>>>>> Is the process of preparing such a map documented somewhere?
>>>>>>
>>>>>> frank
>>>>>>
>>>>>
>>>>> Probably, but I'll do it again: it's from Monticello Configuration Browser:
>>>>> 1) open MC browser
>>>>> 2) select the trunk repository and browse it
>>>>> 3) the bottom package is called update, select it
>>>>> 4) select the top update (update-cwp.227) and click 'browse' button
>>>>> 5) The MC configuration browser that opens lets you
>>>>> - update one (the selected item via pop up menu) or all packages (with
>>>>> update button)
>>>>> * eother from image version or repository version
>>>>> - remove a package from or add a package to the configuration (pop up
>>>>> add new dependency...)
>>>>> - reorder packages
>>>>> 6) once done, post a new update (post button) to squeak trunk
>>>>
>>>> OK, steps 1-4 I knew about. Last time I looked at this guy I didn't
>>>> understand what to do. Thanks!
>>>>
>>>> So in future, any time I move a class from one package to another, I
>>>> must remember that I am _removing_ class Foo and then adding a _new_
>>>> class that happens to have the name Foo.
>>>>
>>>> Now that means there might be a bunch of AnObsoleteFoo instances lying
>>>> around: should the re-adding of Foo be written such that something
>>>> like this happens:
>>>>
>>>>     AnObsoleteFoo allInstances do: [:inst | Foo adoptInstance: inst]
>>>>
>>>> or does/can this happen automatically? (I suspect it can't happen
>>>> automatically.)
>>>>
>>>> frank
>>>>
>>>
>>> No, if you first move the class to package A, then remove it from
>>> package B, it is not removed from Smalltalk globals, because there is
>>> no conflict in B.
>>> So the idea is to load new version of pakage A before new version of
>>> pakage B, which you can control with update configuration load order.
>>>
>>> Nicolas
>>>
>>
>> Hem, my first sentence is a bit misleading, i try again
>> You first load package A which adds the new class (thus you remove it
>> from package B but not from Smalltalk globals)
>
> Shit it's not a new class, I'm really tired, should better stop posting.
> You first load package A which adds the already existing class to A
> (and remove it from B)

So in this case the map should
* add the SmallLand-ColorTheme package (which will move the classes,
rather than remove-then-adding them)
* update the System package.

Right?

frank

>> You then load package B which has no conflict because the class is
>> already removed, so done.
>>
>> Nicolas