[etoys-dev] Preparing for Monticello-based updates

David T. Lewis lewis at mail.msen.com
Tue Apr 20 23:17:08 EDT 2010

On Tue, Apr 20, 2010 at 04:52:02PM -0700, Andreas Raab wrote:
> On 4/20/2010 4:35 PM, Bert Freudenberg wrote:
> >We still need to refine the categorization. I had a crazy idea: in the
> >trunk image, generate a list of which class is in which category, same for
> >all methods. Then recategorize everything in the Etoys image to match that
> >(provided the class/method exists). Since this only recategorizes, it
> >should do no harm. Could that possibly work?
> Yes. I was thinking about the same thing.

Yes it should work. The only caution is that when you recategorize
a class, it ends up looking like a big batch of deletions from one
package, and a batch of additions to some other package. This will
look rather alarming to someone accustomed to tidy change set updates,
so it will be good get these changes done as soon as possible.

> >I have been playing with the idea to keep a traditional update stream in
> >place as fall-back ... in case some surgery is needed that would be
> >infeasible with MC updates.
> I think that's wise, in particular in the early stages. In fact, you
> might consider using the update stream until the dust settles and post
> updated MC packages after installing each update. This could be
> automated and while you're trying to catch up all you'd need to do is to
> load updates first, then merge MC packages and the diffs should be
> empty, no?

And even if it cannot be automated, it is still quite easy to manually
apply the MC updates after change sets are committed. Use the preamble
of the change set as the update comment for the MC update(s), so all
of the comments will be aligned and there is a way to trace the MC
package updates back to the change sets. Typically a single change
set will require updates to more the one MC package, so just paste
the same change set preamble text into each of the affected MC package
commits. It's not perfect, but it's good enough to get started.


More information about the etoys-dev mailing list