[Pharo-dev] Version control of Playground scripts

Shaping shaping at uurda.org
Sat Dec 1 17:59:19 EST 2018

Hi everyone.


These bits on version control are helpful.   


Firmly anchored in VW, I’m trying, on and off, to start a correct/robust Pharo 7 version-control protocol--a groove, a loop that is reliable and aligned with the latest tools, which I gather are Git, Iceberg, Monticello, and Metacello (but I could be wrong about that).  However, I’m not sure which of these will dominate and which will be phased-out—or will all continue to be used indefinitely?  Iceberg seems newest and most preferred.


Can someone point me to the most efficient way to learn how to use the latest version-control tools in Pharo?  There is much to read, and I suspect that it is not all up to date.


http://books.pharo.org/updated-pharo-by-example/pdf/2018-09-29-UpdatedPharoByExample.pdf mentions Monticello, but not Iceberg or Metacello.


https://github.com/pharo-vcs/iceberg/blob/master/docs/Iceberg-glossary.md looks like a good place to start, but I can probably find much better guidance here on the list than from a Google search.






From: Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org] On Behalf Of Norbert Hartl
Sent: Thursday, November 29, 2018 04:32
To: Pharo Dev <pharo-dev at lists.pharo.org>
Subject: Re: [Pharo-dev] Version control of Playground scripts



Am 29.11.2018 um 11:15 schrieb Christopher Fuhrman <christopher.fuhrman at inria.fr <mailto:christopher.fuhrman at inria.fr> >:



On Wed, 28 Nov 2018 at 10:23, Norbert Hartl <norbert at hartl.name <mailto:norbert at hartl.name> > wrote:

Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman <christopher.fuhrman at inria.fr <mailto:christopher.fuhrman at inria.fr> >:


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


This is great. Thanks! 


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. 


I'm a bit lost here: 


1. Are you using Iceberg within Pharo (when you speak of "committing that first"), or are you using only git outside of Pharo? Also, I think it's possible to use a git repo with monticello? 

2. I'm not an advanced git user, so how do I set up my Pharo image directory to work with the 'scripts' folder (again, with Iceberg if possible, as it seems to be the most user-friendly)?


Thanks for your patience with my beginner questions.  


You are welcome. We like to share with people that want to know ;)


The problem in understanding is a hard one. Using git means there are two repositories, one online in the git server and the working copy you checked out locally. When using pharo there is a third one and that is the working copy within your image. Having these two there is a number of conflicts possible. As pharo does not manage external resources like these scripts you can have trouble here. When you go to the command line and commit the script and you go back to pharo it tells you that you are in detached state. It means that the git index is not the same as it was when you loaded stuff via pharo. That is why I was saying that a good flow would first commit the pharo changes and then the ones on the command line. 


Hope this helps,







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.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20181201/cc90a477/attachment.html>

More information about the Pharo-dev mailing list