[Box-Admins] Re: source.squeak.org upgrade

[David T. Lewis]

Hi Chris,

It sounds like a reasonable plan to me.

At first glance, I would say that your #magmaThenFilesystem approach
sounds like a better way to go. For sure we need to have the file system
copy as a backup, but it seems to me that if we are going to use Magma,
then we should just go ahead and use it. Otherwise we would be likely to
invite all of the usual problems with keeping multiple levels of "cache"
in sync.

Dave

> Hi Levente and David (cc:box-admins).  I wanted to see if you have any
> suggestions or feedback for my plan to upgrade the our
> source.squeak.org SqueakSource instance.  My goals are:
>
>     - upgrade the image to latest trunk, and VM to latest 32-bit Spur.
>     - get it out of the chroot environment and running in the normal
> environment on box4
>     - restore the 'mc history' and 'mc origin' functions in the image,
> permanently this time
>     - ability to connect to the server image via RFB instead of having
> to kill and restart it
>     - to improve the speed, scalability and reliability
>
> As you know, our SqueakSource codebase is self-managed at
> http://source.squeak.org/ss.  I'm currently testing the code via my
> own personal SqueakSource server on my LAN with a new subclass of
> SSStorage, called SSCompositeStorage.  The CompositeStorage lets us
> have multiple storage back-ends attached to one server.  This allows
> two new intermediate configurations between a 100% filesystem-only
> backend and a 100% Magma-only backend:
>
>     #filesystemThenMagma -- reads from the filesystem, foreground
> saves to the filesystem, background saves to Magma
>
>     #magmaThenFilesystem -- reads from Magma, foreground saves to
> Magma, background saves to the filesystem.
>
> I think the former is more conservative while the latter should be
> better-performing (although I still plan to do some loading
> benchmarks).  For either configuration, the Magma component enables
> the history on MCDefinitions.
>
> The MagmaSession running inside the server image will require a larger
> memory footprint for the image.
>
> What do you think?
>
> Thanks,
>   Chris
>