[squeak-dev] trunk process resilience

Chris Muller ma.chris.m at gmail.com
Thu Nov 7 21:07:59 UTC 2013


Lately we've had some problems with the SqueakSource server that supports
our vital trunk process.  Ken and I burned several hours on it this week.
 The experience has caused me to consider an idea for improved continuity
of our trunk repository.

Very simply, it's a second running copy of trunk (and inbox, et al).  Each
instance keeps itself up to date from the other.  If one goes down, the
other can be pointed to for updates AND commits to minimize disruption.

Right now, we actually already have two trunks.  Now, I'm pleased to
announce that new-trunk running on box4.squeak.org is now a *full-copy* of
old-trunk on box2.  (Before it was only trunk, now it includes Inbox,
Etoys, etc.).  Using newer and better code and VM and also Magma, this copy
of trunk was originally brought up simply to provide MC method history
directly into the IDE, but now I can see its role being to improve trunk
process stability so that community development can be continuous until it
eventually becomes the defacto trunk (e.g., running source.squeak.org).

There are other side-benefits too, like the ability to move or upgrade the
trunk without a service interruption.  We are assured to be ready to move
to a different server on a moments notice, e.g., break the link with
Hetzner.

So, I guess I'm proposing that we have some elements in the image "aware"
of a second trunk.  But before wrangling out exactly what form that
awareness would take, what do you think so far?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131107/f292010a/attachment-0001.htm


More information about the Squeak-dev mailing list