> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman > <christopher.fuhr...@inria.fr>: > > Hello, > > In Pharo 6.1 I have got Iceberg working and love the interface to GitHub. > Thanks to the Rmod folks for all the patient answers to my newbie questions. > > However, most of my development remains in playground scripts, and as far I > understand, it's not possible to put them under version control with Iceberg. > > My scripts *could* be turned into classes eventually (some already have been > and are under Iceberg). But it feels frustrating to rush it, just to get the > versioning. > > I know how to save Playground files to the web, which is useful, but of > course not version control per se. > > Knowing Playground files are saved on local disk, I got to thinking... What > would be the risk(s) of using git outside Pharo, on the Playground files' > directory? Has anyone tried that before? > It is not a problem. I use this every day. Meaning all my repos have a scripts folder where I put my helper scripts. In the image I open this with
’scripts’ asFileReference inspect so you get kind of a file browser of all the scripts. If you call the files with an extension of .st you get syntax highlighting. If you change a script with cmd-s the file gets modified and you can check into git. The problem here is that if you have modifications in the image you should commit that first because if you do on the scripts folder first the image working copy is detached and there is no easy way to commit your in-image changes. You would have to do a branch which is cumbersome. With the scripts in place I have developed a workflow of creating new images. I have a script that downloads a new image and renames it for the project. And if it finds a script scripts/prepare-image.st <http://prepare-image.st/> it gets executed. This contains metacello commands to load the project code and settings I need in a new image. This way it is super easy to create a new image for your work. And as all the scripts you use are on the filesystem there is usually no state in the image that needs to be transferred to a new image. Norbert
