On Fri, May 23, 2014 at 02:30:36PM -0700, Eliot Miranda wrote:
> On Fri, May 23, 2014 at 12:47 PM, stepharo <stepharo at free.fr> wrote:
> 
> >
> > On 20/5/14 04:41, Rick Kitts wrote:
> >
> > Hello. I was wondering if anyone could point me to or otherwise suggest
> > some best practices for working on Kernel code. I???m futzing about with the
> > Duration class (in the interest of fixing 13215)
> >
> > Thanks!
> >
> >  and have discovered that it???s really easy to crash Pharo if I break that
> > class. I assume there are other classes that would exhibit the same
> > behavior.
> >
> > Yes like Array or OrderedCollection.
> >
> > We are working on a bootstrap of pharo and it could help for brain surgery
> > (but in that case the system may simply not build at all).
> > So the suggestion of Ron to use ChangeSet is a good one.
> >
> 
> But it is also possible to do it with Monticello, using "updates", which
> are really baseline versions of a package.   The idea is to make the
> necessary changes that support your next, potentially suicidal step, commit
> a baseline for that support, and then commit the change that depends on the
> support.  The Monticello update scheme ensures that the baseline is loaded
> before your second commit.  This process can be repeated as many times as
> necessary to make a sequence of interdependent changes happen in order.
> 
> For example, I've just added multiple bytecode support to Squeak trunk.
>  That needed some code on Squeak's BytecodeEncoder and subclasses, which
> are in the Compiler package, *before* loading the Kernel code that depended
> on that BytecodeEncoder support.  If things don't happen in the right order
> the compiler, debugger, and tool facilities such as references &
> assignments would break.

Indeed, the Squeak update stream is wonderful. I remember being initially
worried that MC was too heavyweight to use as a replacement for the change
set update stream. But I was wrong, it works very well and also brings the
benefits of Monticello versioning along for the ride.

It's not just good in theory, either. In practice, I'm usually using a trunk
image, and I am in the habit of doing regular updates from the trunk stream
to make sure I am in sync. It works very well and problems are rare.

This is an interesting contrast with the work flows that I see discussed on
the Pharo list. There, the emphasis seems to be more on the code, so the
idea seems to be to build images that developers will open as fresh environments
into which they will load their code. The working images are treated as
transient artifacts, with the code living in Monticello or git repositories.

It's a perfectly valid approach, and it might well be preferred for large
project teams doing coordinated development. For me personally, I tend to
look at things the other way around. It took me a long time to unlearn some
habits from C and Fortran and sccs and such. But finally I more or less got
the hang of it, and I am now quite comfortable working within a living image
and using the source code tools to take care of the source code.

The thing that really makes this work for me is the update stream. That is
what makes it effortless to maintain a working image, while still keeping
fully in sync with the latest community updates.

Dave