Having ~month old pharo image I was wondering what is the recommended way of updating it. Do I just delete everything and download a fresh one every so often (daily?), do I load new changes through Monticello? Does that upgrade the VM though?
If the former what about local code I wrote but I don't want to loose or haven't completely finished? Is it possible to export workspace content and load it into fresh image? Do I just create local repository and commit there and once I am satisfied with the results I push them up (to STHub/wherever)? Or should I always push to remote repo even if the commits break the package (I would assume that should be semi-guarded by creating ConfigurationOfMyProject)? I am used to Git and I still can't wrap my head around this Monticello thing. :(
Thanks, Peter |
Hi Peter,
I and I guess most people, keep their working image for days to weeks. After all, it is one of the main strengths to have a persistent environment containing all you customisations, all code you loaded, your workspaces, in essence, your world. That being said, you should keep all your important code in an MC repository (at least in the package-cache, but better in a real repository, maybe a private one). That way you know your code will survive an image crash. When and if you want to upgrade, you can now do so. You have to decide if the trouble is worth it. I always keep the old images, just in case. HTH, Sven PS: You can save workspaces to files, or use ScriptManager for multiple ones. There also exists various solutions to move preferences and/or settings around, YMMV. On 24 Jul 2014, at 14:58, Peter Uhnák <[hidden email]> wrote: > Having ~month old pharo image I was wondering what is the recommended way of updating it. Do I just delete everything and download a fresh one every so often (daily?), do I load new changes through Monticello? Does that upgrade the VM though? > If the former what about local code I wrote but I don't want to loose or haven't completely finished? Is it possible to export workspace content and load it into fresh image? > Do I just create local repository and commit there and once I am satisfied with the results I push them up (to STHub/wherever)? Or should I always push to remote repo even if the commits break the package (I would assume that should be semi-guarded by creating ConfigurationOfMyProject)? I am used to Git and I still can't wrap my head around this Monticello thing. :( > > Thanks, > Peter |
Hi, I change my image at least once per day. Every single day. I have automatic jobs that create an up to date images the way I want them, and I simply take that one whenever I feel like it.
This helps me push my code to a repository, and have any setup easily reconstruct-able. If a piece of code does not make it in even a playground repository, it is probably not worth having it around anyway.
For me, it is a matter of principle. Cheers, Doru On Thu, Jul 24, 2014 at 3:17 PM, Sven Van Caekenberghe <[hidden email]> wrote: Hi Peter, "Every thing has its own flow"
|
On Thu, Jul 24, 2014 at 3:27 PM, Tudor Girba <[hidden email]> wrote:
> I change my image at least once per day. Every single day. I have automatic > jobs that create an up to date images the way I want them, and I simply take > that one whenever I feel like it. I agree I do the same. Jenkins and the Pharo Launcher are very useful for such a process. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill |
In reply to this post by Sven Van Caekenberghe-2
Sven Van Caekenberghe wrote:
Peter,Hi Peter, I and I guess most people, keep their working image for days to weeks. After all, it is one of the main strengths to have a persistent environment containing all you customisations, all code you loaded, your workspaces, in essence, your world. That being said, you should keep all your important code in an MC repository (at least in the package-cache, but better in a real repository, maybe a private one). That way you know your code will survive an image crash. You may want to use a local "Global Package Cache" as described here... http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/ which you can use with StartupLoader as described here... http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/ cheers -ben When and if you want to upgrade, you can now do so. You have to decide if the trouble is worth it. I always keep the old images, just in case. HTH, Sven PS: You can save workspaces to files, or use ScriptManager for multiple ones. There also exists various solutions to move preferences and/or settings around, YMMV. On 24 Jul 2014, at 14:58, Peter Uhnák [hidden email] wrote:Having ~month old pharo image I was wondering what is the recommended way of updating it. Do I just delete everything and download a fresh one every so often (daily?), do I load new changes through Monticello? Does that upgrade the VM though? If the former what about local code I wrote but I don't want to loose or haven't completely finished? Is it possible to export workspace content and load it into fresh image? Do I just create local repository and commit there and once I am satisfied with the results I push them up (to STHub/wherever)? Or should I always push to remote repo even if the commits break the package (I would assume that should be semi-guarded by creating ConfigurationOfMyProject)? I am used to Git and I still can't wrap my head around this Monticello thing. :( Thanks, Peter |
Thank you all so much! This is is exactly what I was looking for and a lot more. On Thu, Jul 24, 2014 at 6:29 PM, Ben Coman <[hidden email]> wrote:
|
In reply to this post by Peter Uhnak
If you use a shared package cache, you should be aware of two potential issues:
- directories with a large number of files can get slow; - Metacello configurations might load different versions of packages than you'd expect Stephan |
Am 24.07.2014 um 23:43 schrieb Stephan Eggermont <[hidden email]>: > If you use a shared package cache, you should be aware of two potential issues: > - directories with a large number of files can get slow; I don't think that this is an issue with todays filesystems. If you want to cleanup a package-cache you could use something like this ---- $ cat bin/clean-package-cache #!/bin/sh find /opt/mc/package-cache/ -atime +180d -exec mv {} ~/.Trash \; —— It moves all files that have not been accessed for half a year into the trash folder (I'm a Mac user). You can have this run automatically if add a file ---- $ cat Library/LaunchAgents/org.selfish.cleanPackageCache.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.selfish.cleanPackageCache</string> <key>ProgramArguments</key> <array> <string>/Users/norbert/bin/clean-package-cache</string> </array> <key>StartInterval</key> <integer>86400</integer> </dict> </plist> —— > - Metacello configurations might load different versions of packages than you'd expect Indeed Norbert |
But isn't that a bit... weird to use cache to move data from one image to another? I would expect cache to be just a cache even if in reality it is just a regular repository. On Fri, Jul 25, 2014 at 12:48 AM, Norbert Hartl <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |