On Fri, May 23, 2014 at 12:47 PM, stepharo <[hidden email]> wrote:
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.
By all means use the change list for crash recovery, or even change sets. But unlike change sets, Monticello's updates provide support for any number of steps. Typically with a change set you have to manually reorder things. I've used change sets a lot in the past to pull off a number of "adventurous" system changes. But now I'm familiar with Monticello it feels like its by far the best way.
best, Eliot
|
On Fri, May 23, 2014 at 02:30:36PM -0700, Eliot Miranda wrote:
> On Fri, May 23, 2014 at 12:47 PM, stepharo <[hidden email]> 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 |
Free forum by Nabble | Edit this page |