Hi Rick,
Actually that makes sense. The change set dance and the changes file for recovering code after a crash are really about keeping your repo clean. It’s helpful for larger groups of developers that don’t want to have to track everything you do that doesn’t work J. It also prevents people from loading code that breaks the system. For me I only post my final work to the repo. You can also do that with Monticello using the local cache. Then you only post to the main repo by merging your versions into the trunk and releasing those. It just takes longer than using a change set. Monticello also has a config map but still you have to version every package and then load all of your packages again at startup. With the change set it’s file out, restart, file in. Good luck with it! All the best, Ron Teitelbaum From: Rick Kitts [mailto:[email protected]] Sent: Tuesday, May 20, 2014 11:45 PM To: Pharo Development List; Ron Teitelbaum Subject: Re: [Pharo-dev] Advice for a newb Thanks for the advice. I have spent some quality time with Monticello. In the end I’ve made a copy of Duration and DurationTest and I’m working on that. I’m not doing the image juggling you describe below however. I don’t really understand why that workflow is worth the cost so I’ll just keep getting closer to the stove until I get burned. I’ll (probably) learn then. —Rick On May 19, 2014 at 8:53:10 PM, Ron Teitelbaum ([email protected]) wrote: Hi Rick, Change sets and changes file will save you no matter how you crash your image. Saving your image after development is dangerous, I don’t recommend it. What I do is make a change set. I’ll develop and then when I’m ready to start testing I’ll file it out. I’ll do some testing blow up develop more. If I forget to file out the change set the changes file is your friend. World menu -> changes… -> recently logged changes … will give you a nice list of the last things you did. It’s quite easy to filter out stuff and get a nice list of changes, and file them in. It is very hard to lose code. When you get to a good point and want to save your state always start from your last saved image. Load your change set, save your changes to Monticello, or your own favorite repo. Exit, load your changes from your repo, clean your image and save. Now your recently logged changes will have another nice clean entry. Rinse and repeat. Hope that helps. All the best, Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting [email protected] Follow Me On Twitter: @RonTeitelbaum <https://twitter.com/RonTeitelbaum> www.3dicc.com <http://www.3dicc.com/> https://www.google.com/+3dicc From: Pharo-dev [mailto:[email protected]] On Behalf Of Rick Kitts Sent: Monday, May 19, 2014 10:41 PM To: Pharo Development List Subject: [Pharo-dev] Advice for a newb 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) 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. I suppose I could just be really cautious and save my image after every change but that seems so error prone that I’m hoping that there are idiomatic ways of working on kernel code (beyond just save ones image early and often) so I don’t lose work. I’m asking because the naive solution (copy the original class, modify it to suit, delete the original and rename the new class to the original) of course doesn’t work. TIA for any suggestions or assistance and apologies in advance if this is RTFM, I didn’t see anything (didn’t look very hard either though). —Rick
