[squeak-dev] Instructions for updating trunk undate config

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Feb 14 20:32:44 UTC 2018


2018-02-14 10:04 GMT+01:00 Bert Freudenberg <bert at freudenbergs.de>:

>
> On Tue 13. Feb 2018 at 20:38, Chris Cunningham <cunningham.cb at gmail.com>
> wrote:
>
>> Hi Eliot,
>>
>> On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>> > On Feb 10, 2018, at 1:48 PM, Chris Cunningham <cunningham.cb at gmail.com>
>>> wrote:
>>> >
>>> > This one I'm going to need some help on, having never done this before
>>> (obviously).
>>> >
>>> > -----
>>> > When and How to change the trunk update configuration:
>>> > * When you are adding a new package to trunk, update the configuration
>>> with the new package (just because a package is in the repository does not
>>> mean it is loaded)
>>> > * When you are removing a package from trunk, update the configuration
>>> to remove the package (and follow instructions for removing the package)
>>> > * When methods are moved from one package to another - primarily when
>>> they are used in the update logic - then create an update with the package
>>> where the method is removed and where the method is added in the same
>>> update configuration
>>>
>>> That's not the safest.  The safest is to create a configuration with the
>>> package to which the method is moved, but still containing the version of
>>> the package from which the method had moved which still had the method.
>>> This way, the package from which the method is moved will be marked dirty
>>> but there is no chance of the method being lost.
>>>
>>> I wasn't sure where the conversation between you and Bert left off on
>> this subject.  I can certainly change this to be this way - especially
>> since it is safer (leaving the Bert enhancement to cover places where we
>> weren't aware that happened, maybe.  Although we should be aware.).
>>
>> Another question: should we ALWAYS create a config when a method (or
>> class) moves from one package to another?
>>
>> -cbc
>>
>
>
>
> IMHO we have way too many config maps already.
>
> We don't need any config maps even for moving methods between packages.
>
> The only time when you actually need an explicit config map is when you
>  are doing open-heart surgery on the kernel.
>
> This is because besides the explicit config maps, the implicit map loaded
> at the end of the  updater usually takes care of everything. It is created
> on the fly by taking the last published config map and updating it with the
> latest packages from trunk.
>
> Creating unnecessary config maps just slows down the update process.
>
> - Bert -
>
>>
>
> +1

Other cases: renaming a class is not traced by MC version control
This is seen as addition of a class NewName and deletion of class OldName.
If there are instances of OldName that we want to migrate, then we have to
use some preamble/postscript
1) publish NewName, use NewName in client code,  and becomeForward: OldName
allInstances in postscript
2) Remove OldName and suppress postscript

That means at least one update map entry for 1)
Note that if ever a block refering to OldName is forked, then the process
has to be restarted with some surgery...

An alternative would be to script the class rename in some preamble...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180214/29300fa2/attachment.html>


More information about the Squeak-dev mailing list