Re: [Pharo-dev] Version control of Playground scripts

[Sean P. DeNigris]

Shaping1 wrote
> Git, Iceberg, Monticello, and Metacello...  However, I’m not sure which of
> these will dominate and which will be phased-out

tl;dr: Use Iceberg and Metacello, which use git (for now, eventually there
should be other mainstream options) and Monticello for you. If you're
insterested in the gory details, see Ben's and my answers in this thread:
http://forum.world.st/What-is-the-actual-way-of-managing-code-in-Pharo-tp5089943.html

I don't know of any great documentation on the newest Iceberg, because it is
a brand new redesign of the other tool, but docs on v. 1 will get you in the
spirit and then you can ask lots of questions on Discord.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Version control of Playground scripts

[Shaping]

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.

 

Thanks.

 

Shaping

 

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

 

 





Am 29.11.2018 um 11:15 schrieb Christopher Fuhrman 
mailto:christopher.fuhr...@inria.fr> >:

 

 

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

Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman 
mailto:christopher.fuhr...@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,

 

Norbert





Cheers,

 

Christopher

 

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

 

 

 

Re: [Pharo-dev] Version control of Playground scripts

[Norbert Hartl]

> Am 29.11.2018 um 11:15 schrieb Christopher Fuhrman 
> :
> 
> 
> 
> On Wed, 28 Nov 2018 at 10:23, Norbert Hartl  > wrote:
>> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman 
>> mailto:christopher.fuhr...@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,

Norbert

> Cheers,
> 
> Christopher
>  
> 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 
> 
> 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
> 
> 

Re: [Pharo-dev] Version control of Playground scripts

[Christopher Fuhrman]

On Wed, 28 Nov 2018 at 10:23, Norbert Hartl  wrote:

> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman <
> christopher.fuhr...@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.

Cheers,

Christopher


> 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
>
> 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
>
>
>

Re: [Pharo-dev] Version control of Playground scripts

[Norbert Hartl]

> Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman 
> :
> 
> 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 

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

Re: [Pharo-dev] Version control of Playground scripts

[Esteban Lorenzano]

Hi,

> On 28 Nov 2018, at 09:38, Christopher Fuhrman  
> wrote:
> 
> 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 should be possible without any risk.
You should: 
a) Redirect playground cache to some place you want (option is somewhere in 
settings…)
b) Version those from outside.

And the only drawback is that you will need to “repair” your image project each 
time you do that, because the project will move to “detached state”. But repair 
is easy: just merge with your branch (99% of the time it will do a fast 
forward).

Esteban

> 
> Cheers,
> 
> Christopher
> 

[Pharo-dev] Version control of Playground scripts

[Christopher Fuhrman]

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?

Cheers,

Christopher