Yes, it is a remnant although there is no harm it in being there since it will
show you where your image left off in the squeak46 update stream before someone
switched it over to the trunk update stream.

We should probably add "MCMcmUpdater clearRegistry" to ReleaseBuilder so that
is done the next time we make a release (I'm not very familiar with ReleaseBuilder
so I won't try it right now).

  MCMcmUpdater class>>clearRegistry
        "Save the current default updater, clear the registry, and re-register the current updater.
        This is intended for cleaning up an image prior to public release. Assumes that the
        current updater is the one intended for ongoing use in this image."

Note that this will have no effect on the repositories that show up in your
Monticello browsers. These get tidied up somehow when new releases are made
(I don't know the details).

Dave

On Sun, Oct 22, 2017 at 10:07:54PM +0200, Bernhard Pieber wrote:
> Hi Dave,
> 
> Thanks for your answer. IIUC it is a remnant and could be removed from all packages in the trunk image, right?
> 
> Cheers,
> Bernhard
> 
> > Am 22.10.2017 um 19:49 schrieb David T. Lewis <lewis at mail.msen.com>:
> > 
> > On Sun, Oct 22, 2017 at 06:26:37PM +0200, Bernhard Pieber wrote:
> >> Dear Squeakers,
> >> 
> >> I was looking at the MCMcmUpdater class trying to find a way to identify the exact place in the update process where the packages get dirty. I wonder how do others debug problems with the update process.
> >> 
> >> I tripped over something strange. In each of the Registry and Updaters class vars there is a reference to an MCMcmUpdater instance for http://source.squeak.org/squeak46 in addition to one for http://source.squeak.org/trunk. Does this have a reason or is this a glitch?
> >> 
> > ,
> > Hi Bernhard,
> > 
> > It is just the saved state from when the preference for "Update URL" was set to
> > 'http://source.squeak.org/squeak46'. The 4.6 image would have been initially set
> > for that preference, then changed to 'http://source.squeak.org/trunk' for following
> > the trunk update stream.
> > 
> > In earlier days, the updater was all class side methods suitable for following
> > only one update stream. More recently it has been changed to allow multiple
> > updaters, which is useful if you want to maintain update streams for different
> > projects, such as a trunk update stream along with a VMMaker update stream in
> > the same image.
> > 
> > Dave
>