Re: Versioning with Iceberg

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Shaping1

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

Shaping

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

ducasse
Hello

Can you tell us what you are doing?
Because if a project loads always the head then iceberg will load it. 
Or you should specify a specific commit. 

Stef

On 29 May 2019, at 11:07, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable.  
 
How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.
 
Shaping

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Ben Coman
In reply to this post by Shaping1


On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.



Its not completely clear what you want.  

You can right-click a repo > Metacello > Install baseline of.....

Or right-click a repo > Repository > Remotes 
and select one of those branches to check out.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Shaping1
In reply to this post by ducasse

…Trying to have 7.0.3 as my base, not 8.0.  I’m not sure what happened with the VM crash, but I can do without the latest version for now.

 

How do I specify the commit with Iceberg?

 

 

Shaping

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of ducasse
Sent: Wednesday, May 29, 2019 10:17
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Versioning with Iceberg

 

Hello

 

Can you tell us what you are doing?

Because if a project loads always the head then iceberg will load it. 

Or you should specify a specific commit. 

 

Stef



On 29 May 2019, at 11:07, Shaping <[hidden email]> wrote:

 

I’m finding 7.0.3 to be more stable.  

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

Shaping

 

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Shaping1
In reply to this post by Ben Coman

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

 

Its not completely clear what you want.  

 

You can right-click a repo > Metacello > Install baseline of.....

Or right-click a repo > Repository > Remotes 
and select one of those branches to check out.

 

The baselines look specialized.  I want Pharo 7.0.3, not just one package. 

 

Shaping

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Shaping1
In reply to this post by Ben Coman

 

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Wednesday, May 29, 2019 10:58
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Versioning with Iceberg

 

 

 

On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

 

Its not completely clear what you want.  

 

You can right-click a repo > Metacello > Install baseline of.....

Or right-click a repo > Repository > Remotes 
and select one of those branches to check out.

 

I missed the Repository item completely, all this time.  I think I was blocking it out mentally because I was already in an Iceberg window that lists repos.  The doubling up is confusing and unexpected.   So we have Iceberg repos wrapping Git repos?  I’m not sure I have the scheme right.

 

Why don’t we have the usual wait-cursors appearing on long synchronous actions behind button clicks?  These lock up the system for 1 or 2 minutes often.  For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor).  This happens when cloning a Git repo, too.  The histo opens about ½ second before the about 1-m pull finishes.  This happened in the 7.0.3 build.  Is there a policy not to use a wait-cursor if not histo is shown?

 

Shaping

 

Reply | Threaded
Open this post in threaded view
|

FW: Versioning with Iceberg

Shaping1
In reply to this post by Ben Coman

Sorry, I meant progress bar, not histo….

 

From: Shaping [mailto:[hidden email]]
Sent: Wednesday, May 29, 2019 20:05
To: 'Pharo Development List' <[hidden email]>
Subject: RE: [Pharo-dev] Versioning with Iceberg

 

 

 

From: Pharo-dev [[hidden email]] On Behalf Of Ben Coman
Sent: Wednesday, May 29, 2019 10:58
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Versioning with Iceberg

 

 

 

On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

 

Its not completely clear what you want.  

 

You can right-click a repo > Metacello > Install baseline of.....

Or right-click a repo > Repository > Remotes 
and select one of those branches to check out.

 

I missed the Repository item completely, all this time.  I think I was blocking it out mentally because I was already in an Iceberg window that lists repos.  The doubling up is confusing and unexpected.   So we have Iceberg repos wrapping Git repos?  I’m not sure I have the scheme right.

 

Why don’t we have the usual wait-cursors appearing on long synchronous actions behind button clicks?  These lock up the system for 1 or 2 minutes often.  For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor).  This happens when cloning a Git repo, too.  The histo opens about ½ second before the about 1-m pull finishes.  This happened in the 7.0.3 build.  Is there a policy not to use a wait-cursor if not histo is shown?

 

Shaping

 

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Tim Mackinnon
Hi - I’m rather confused reading your thread as it’s not clear what you’re doing.

Using iceberg - I typically see the normal loading progress bars for long operations on the top left of the screen - often they stack below one another to show nested operations (aside: they are a bit ugly - but it’s a consistent metaphor across Pharo). I get them when loading, pulling, pushing, diffing etc. Do you not see them?

Back to your version question - what baseline are you loading from a repo? A specific example might help.

If i were to load Exercism as an example - the following page describes how to upgrade to a specific version of the baseline in the repo.

Eg latest vs v0.2.3



This describes how to do it in the playground - as versions are actually loaded by metacello - and Iceberg builds on top of it to route things via git and make use of version tags etc, and it then gives the push/pull/commit operations. (I’m probably describing this badly - but I suspect the confusion is in here for you).

Having loaded your particular baseline (the code tagged as v2.0.3 for example), Iceberg will let you compare it to other branches - or hash versions in git.

But typically, libraries you use will give you a playground script that specifies a stable version - you eval that in your playground and those libraries will then appear in your image (and also in Iceberg).

For your project - you can formalise those dependencies by creating your own baseline that references those scripts as well.

But maybe you can describe better what you are doing and we can unpick what is happening.

Tim

Sent from my iPhone

On 30 May 2019, at 02:07, Shaping <[hidden email]> wrote:

Sorry, I meant progress bar, not histo….

 

From: Shaping [[hidden email]]
Sent: Wednesday, May 29, 2019 20:05
To: 'Pharo Development List' <[hidden email]>
Subject: RE: [Pharo-dev] Versioning with Iceberg

 

 

 

From: Pharo-dev [[hidden email]] On Behalf Of Ben Coman
Sent: Wednesday, May 29, 2019 10:58
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Versioning with Iceberg

 

 

 

On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

 

Its not completely clear what you want.  

 

You can right-click a repo > Metacello > Install baseline of.....

Or right-click a repo > Repository > Remotes 
and select one of those branches to check out.

 

I missed the Repository item completely, all this time.  I think I was blocking it out mentally because I was already in an Iceberg window that lists repos.  The doubling up is confusing and unexpected.   So we have Iceberg repos wrapping Git repos?  I’m not sure I have the scheme right.

 

Why don’t we have the usual wait-cursors appearing on long synchronous actions behind button clicks?  These lock up the system for 1 or 2 minutes often.  For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor).  This happens when cloning a Git repo, too.  The histo opens about ½ second before the about 1-m pull finishes.  This happened in the 7.0.3 build.  Is there a policy not to use a wait-cursor if not histo is shown?

 

Shaping

 

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Shaping1

Using iceberg - I typically see the normal loading progress bars for long operations on the top left of the screen - often they stack below one another to show nested operations (aside: they are a bit ugly - but it’s a consistent metaphor across Pharo). I get them when loading, pulling, pushing, diffing etc. Do you not see them?

 

I do, but not reliably.  Sometimes I wait as I said until the loading threat is done.  Then the GUI gets a chance to run, and the progress bar appears at the last moment (99% or so).

 

Back to your version question - what baseline are you loading from a repo? A specific example might help.

 

7.0.3.  It loaded after a fresh clone of pharo, but with a detached head.

 

If i were to load Exercism as an example - the following page describes how to upgrade to a specific version of the baseline in the repo.

 

Eg latest vs v0.2.3

 

 

 

This describes how to do it in the playground - as versions are actually loaded by metacello - and Iceberg builds on top of it to route things via git and make use of version tags etc, and it then gives the push/pull/commit operations. (I’m probably describing this badly - but I suspect the confusion is in here for you).

 

 

Hours later the “Checking out v7.0.3 from pharo” progress bar is still stuck.  How is the stuck progress bar related to the detached head?

 

Having loaded your particular baseline (the code tagged as v2.0.3 for example), Iceberg will let you compare it to other branches - or hash versions in git.

 

But typically, libraries you use will give you a playground script that specifies a stable version - you eval that in your playground and those libraries will then appear in your image (and also in Iceberg).

 

Yes, I want all of Pharo 7.0.3 this time.

 

I prefer to use one tool for versioning.  Is that possible now in any version of Pharo?  Can I use only Iceberg for all fetches and all commits?   Or must I sometimes use evaluables like:

 

Metacello new

 baseline: 'Exercism';

 repository: 'github://exercism/pharo-smalltalk/releases/latest';

onConflict: [ :ex | ex allow ];

 load.

 

?

 

For your project - you can formalise those dependencies by creating your own baseline that references those scripts as well.

 

I’ll do that once I get the basics working.  The problems may be related to not using default install folders.  I’m not sure yet.

 

 

Shaping

 


On 30 May 2019, at 02:07, Shaping <[hidden email]> wrote:

Sorry, I meant progress bar, not histo….

 

From: Shaping [[hidden email]]
Sent: Wednesday, May 29, 2019 20:05
To: 'Pharo Development List' <[hidden email]>
Subject: RE: [Pharo-dev] Versioning with Iceberg

 

 

 

From: Pharo-dev [[hidden email]] On Behalf Of Ben Coman
Sent: Wednesday, May 29, 2019 10:58
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] Versioning with Iceberg

 

 

 

On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

 

Its not completely clear what you want.  

 

You can right-click a repo > Metacello > Install baseline of.....

Or right-click a repo > Repository > Remotes 
and select one of those branches to check out.

 

I missed the Repository item completely, all this time.  I think I was blocking it out mentally because I was already in an Iceberg window that lists repos.  The doubling up is confusing and unexpected.   So we have Iceberg repos wrapping Git repos?  I’m not sure I have the scheme right.

 

Why don’t we have the usual wait-cursors appearing on long synchronous actions behind button clicks?  These lock up the system for 1 or 2 minutes often.  For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor).  This happens when cloning a Git repo, too.  The histo opens about ½ second before the about 1-m pull finishes.  This happened in the 7.0.3 build.  Is there a policy not to use a wait-cursor if not histo is shown?

 

Shaping

 

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Ben Coman
On Thu, 30 May 2019 at 18:56, Shaping <[hidden email]> wrote:

 

I prefer to use one tool for versioning.  Is that possible now in any version of Pharo?  Can I use only Iceberg for all fetches and all commits?   Or must I sometimes use evaluables like:

 

Metacello new

 baseline: 'Exercism';

 repository: 'github://exercism/pharo-smalltalk/releases/latest';

onConflict: [ :ex | ex allow ];

 load.


Metacello operates at a higher level than Iceberg.  
Iceberg (like Monticello) versions individual packages.  
Metacello defines the version dependencies between packages, including different git repos and Monticello repos.  
The Metacello definition is versioned like any other code, using either Iceberg or Monticello.

I'm not completely sure, but I think Metacello uses Iceberg to load from github repos,
so what that last code snippet does is...
Metacello loads the given baseline from github using Iceberg and parses it,
then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in,
then loads all the specified code versions using Iceberg or Monticello as appropriate.

Also once you've loaded an Iceberg repo containing a Metacello baseline,
you can invoke that baseline from within Iceberg. 
image.png

Essentially Iceberg replaces Monticello for git repos,
but there is a wealth of historical packages in Monticello format, so its not disappearing either.

HTH,
cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Ben Coman
In reply to this post by Shaping1


On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.




cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Tim Mackinnon
In reply to this post by Shaping1


On 30 May 2019, at 11:55, Shaping <[hidden email]> wrote:

7.0.3.  It loaded after a fresh clone of pharo, but with a detached head.


So are you trying to actually contribute to Pharo? You don’t normally need to reload pharo (if I’ve understood what you are doing). I think ben has raised a bug for you for that.

However, back to your other question - I had misunderstood - actually you can load specific project (like exercism)  via Iceberg (although a metacello script is often more convenient - and sometimes more precise) - if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but won’t load any packages).

Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. ‘dev’ for exercism).

If you want a different version than master, then have to open the repository view (cmd-r), there you can select a tag to load, and then you can use the metecallo menu.

You can also (although somewhat painfully), right click on all the packages in a repository and select “load” to do them one by one.

Hope this helps.

Tim

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Shaping1
In reply to this post by Ben Coman

Thanks for the explanation, Ben.   This isn’t good for the future of Pharo.   What a headache. 

 

Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git?  I don’t see how this will ever be done or finished manually, humans being what they are.  The fragmented versioning-technologies will persist then indefinitely.

 

 

Shaping

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Thursday, May 30, 2019 08:45
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] FW: Versioning with Iceberg

 

On Thu, 30 May 2019 at 18:56, Shaping <[hidden email]> wrote:

 

I prefer to use one tool for versioning.  Is that possible now in any version of Pharo?  Can I use only Iceberg for all fetches and all commits?   Or must I sometimes use evaluables like:

 

Metacello new

 baseline: 'Exercism';

 repository: 'github://exercism/pharo-smalltalk/releases/latest';

onConflict: [ :ex | ex allow ];

 load.

 

Metacello operates at a higher level than Iceberg.  

Iceberg (like Monticello) versions individual packages.  

Metacello defines the version dependencies between packages, including different git repos and Monticello repos.  

The Metacello definition is versioned like any other code, using either Iceberg or Monticello.


I'm not completely sure, but I think Metacello uses Iceberg to load from github repos,
so what that last code snippet does is...
Metacello loads the given baseline from github using Iceberg and parses it,

then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in,

then loads all the specified code versions using Iceberg or Monticello as appropriate.

 

Also once you've loaded an Iceberg repo containing a Metacello baseline,
you can invoke that baseline from within Iceberg. 

image.png

 

Essentially Iceberg replaces Monticello for git repos,

but there is a wealth of historical packages in Monticello format, so its not disappearing either.

 

HTH,

cheers -ben

 

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Ben Coman


On Fri, 31 May 2019 at 09:09, Shaping <[hidden email]> wrote:

Thanks for the explanation, Ben.   This isn’t good for the future of Pharo.  


Could you expand your thoughts on that?
I don't see why.  Linux didn't fall apart with the introduction of... tar, rpm, yum, apt, dnf, etc...

What a headache. 


I don't find it so.  What is the headache for you?  
is it confusion about the scope of each? Maybe we need to better communicate this?  
 

 Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git? 


I believe there has been some work.  If no better answers come, search http://forum.world.st/ 
 

I don’t see how this will ever be done or finished manually, humans being what they are. 


What you a promoting is forcing a monoculture.  Humans being what they are, don't respond well to that.
  

The fragmented versioning-technologies will persist then indefinitely.


Iceberg/git in only been in broad use for one year since release of Pharo 7.    
How fast do you expect the world to change?
The diffusion of innovation applies... https://en.wikipedia.org/wiki/Diffusion_of_innovations

Some people work in multiple Smalltalk versions that continue to use Monticello (http://www.squeaksource.com)
and want to maintain a cross-platform package.  So even with the most perfect conversion script, Monticello will remain an option.

The alternative scenario of having only one versioning system 
would have been to stick with Monticello and avoid using git.  
I don't consider that viable.  

I believe Pharo has a great future with a preferred option going forward with Git
and an option to access legacy code with Monticello.

cheers -ben
 

 

 

Shaping

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Thursday, May 30, 2019 08:45
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] FW: Versioning with Iceberg

 

On Thu, 30 May 2019 at 18:56, Shaping <[hidden email]> wrote:

 

I prefer to use one tool for versioning.  Is that possible now in any version of Pharo?  Can I use only Iceberg for all fetches and all commits?   Or must I sometimes use evaluables like:

 

Metacello new

 baseline: 'Exercism';

 repository: 'github://exercism/pharo-smalltalk/releases/latest';

onConflict: [ :ex | ex allow ];

 load.

 

Metacello operates at a higher level than Iceberg.  

Iceberg (like Monticello) versions individual packages.  

Metacello defines the version dependencies between packages, including different git repos and Monticello repos.  

The Metacello definition is versioned like any other code, using either Iceberg or Monticello.


I'm not completely sure, but I think Metacello uses Iceberg to load from github repos,
so what that last code snippet does is...
Metacello loads the given baseline from github using Iceberg and parses it,

then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in,

then loads all the specified code versions using Iceberg or Monticello as appropriate.

 

Also once you've loaded an Iceberg repo containing a Metacello baseline,
you can invoke that baseline from within Iceberg. 

image.png

 

Essentially Iceberg replaces Monticello for git repos,

but there is a wealth of historical packages in Monticello format, so its not disappearing either.

 

HTH,

cheers -ben

 

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Shaping1
In reply to this post by Ben Coman

On Wed, 29 May 2019 at 23:08, Shaping <[hidden email]> wrote:

I’m finding 7.0.3 to be more stable. 

 

How do I load a specific baseline/version with Iceberg?  I’m getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0.  There are many differences.  I want to commit my image changes locally for now on a 7.0.3.

 

 

 

Yes, this seems to describe my confusing scenario exactly.  Thanks.

 

The thought is:   Pharo 3.0.7 knows that it is version 3.0.7.  Why then is Iceberg fetching by default version 8.0 from the Git repo?  This destroys your confidence in the versioning system or, in my case, in the Pharo install itself, because I chose non-default folders, and am still wondering whether this is an issue.  Can the handler of the installer of Pharo Launcher perhaps do an install to non-default folders, and test this idea.   Can we tweak the installer of Pharo Launcher so that it will allow installation outside the user-account folder, without having first to create a folder under Program Files (x86) and add permissions? 

 

I’ve managed to crash the VM twice, with both Pharo 8 and Pharo 3.0.7, just by cloning a Git repo via Iceberg, and then by using Iceberg to fetch a version.   Sometime during those calculations/comparisons, the VM crashed.  I also used Iceberg to delete the pharo repo at several points, in order to start the exercise over.  It worked, but Pharo was un-responsive in a tight synchronous thread during this operation, and there was no indication that anything sane was happening, not even a wait cursor.   I’m wondering why we choose to leave the user wondering for long stretches (many minutes during the Iceberg/Git repo delete and 1 to 2 minutes during the earlier 20-odd-package delete) what is happening inside his Smalltalk image.  Can someone explain the no-wait-cursor default in Pharo GUIs?

 

Can someone look at the .dmp file I attached to the e-mail describing the first VM crash, and tell me what he thinks happened?  I saw mentions of a stack overflow.  I still have the .dmp file from the second VM crash with Pharo 3.0.7, if anyone wants to see it.

 

 

Shaping

Reply | Threaded
Open this post in threaded view
|

Re: Versioning with Iceberg

Shaping1
In reply to this post by Tim Mackinnon

On 30 May 2019, at 11:55, Shaping <[hidden email]> wrote:

 

7.0.3.  It loaded after a fresh clone of pharo, but with a detached head.

 

 

So are you trying to actually contribute to Pharo? You don’t normally need to reload pharo (if I’ve understood what you are doing). I think ben has raised a bug for you for that.

 

Yes, generally to start, I need to track my changes on 7.0.3, save them down to a local repo, and have a way to use that local repo (Iceberg-on-Git repo) to regenerate an image that is 7.0.3 plus my stuff or 8.0 plus my stuff when 8.0 is in better shape.

 

This is a really important loop for anyone trying to switch environs, and it should get lots of attention and TLC from Pharo veterans wanting Smalltalkers to migrate to Pharo.  If the new guy can do that loop reliably and repeatedly, the probability that he sticks around and pushes on with Pharo, instead of running back home to VW (done this a lot), increases greatly.  And along the way, there should be no VM crashes.   I still need to determine what caused those. 

 

However, back to your other question - I had misunderstood - actually you can load specific project (like exercism)  via Iceberg (although a metacello script is often more convenient - and sometimes more precise)

 

That bit is golden, and worries me.  Can we make Iceberg do what Metacello does (the thorough dependency structure) as well as it does, and phase-out Metacello? 

 

- if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but won’t load any packages).

 

After I do the above, Iceberg lists a repo called pharo-smalltalk.  Was this intentional?

 

https://github.com/exercism/pharo-smalltalk

 

Above is the Exercism GitHub page.  The URL and doc mention both Exercism and pharo-smalltalk, but the former is not found in the GUI anywhere to tell the user what he has (without additional digging).

 

I just cloned Exercism.  I thought it would be identified somewhere besides in the Git commit comments.  The Iceberg repo context menu item Repository (strange name given that we are already in an Iceberg repo) lists the repo as ‘Repository of pharo-smalltalk’  with a master node, origin node and several version tags.  These can’t be Pharo versions because the numbers are too small.   They must be Exercism versions, but ‘exercism’ isn’t mentioned anywhere, except in some of the Git commit comments, or I missed it.  So there is some immediate disorientation on that account.  If I choose Packages on the Iceberg repo context menu, I can see that this repo is all about Exercism.  Should we need to dig even one step into an Iceberg repo to remind ourselves of what we have?  I would think that a clear identifier for the Repo would be created immediately after the initial connection using the project name and owner data.  (BTW, is there a complete list of all pharo project repos showing the correct spellings of the project and owner names?  That would be a great place to start.)

 

Is there a more ergonomic way to present an Iceberg repo?

 

Would the Iceberg GUI make more sense as a split pane arrangement where the stuff listed in the Repository window is shown in the right pain after selecting a well-named Iceberg repo in the left pane?  We could have bubble-help on the listed repos and details in the right pane on repo selection.

 

Checking out the latest tag didn’t seem to do anything.

 

The Iceberg repo show Detached HEAD? 

 

Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. ‘dev’ for exercism).

 

 

I loaded the default baseline and see 4 packages up to date and the rest unloaded.

 

When I tried ‘dev’ I got an assertion failure on the SSH creds.  Did I miss a step concerning SSH creds on install?  But the loading seemed to continue.

 

I also got the error:

 

LGit_GIT_EEXISTS: Failed to stat file 'F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo...derReturnedAnotherObjectAndNobodyReturnedGivenObject.st': The filename or extension is too long.

 

Here’s the file name that was too long:

 

 

F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st'

 

There seems to be a general problem with the context of a walkback when something goes wrong. In some, not all cases, I don’t see the error window until long after the error has occurred.  It does not pop up in view when the error happens.   I find it later while poking around.  It’s probably in the tab list at the bottom, but I don’t see it until the original context of the error is gone.   This one probably happened when I tried to load the Exercism base line using ‘dev’.

 

If you want a different version than master, then have to open the repository view (cmd-r), there you can select a tag to load, and then you can use the metecallo menu.

 

Yeah, doesn’t work.  Probably related to the detached HEAD.   How can I fix this from inside Iceberg?

 

You can also (although somewhat painfully), right click on all the packages in a repository and select “load” to do them one by one.

 

Right.

 

Hope this helps.

 

It does.  But this tool is painful to use, and my install or usage pattern is still broken.  Not sure which yet. 

 

 

Shaping

 

 

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Shaping1
In reply to this post by Ben Coman

Could you expand your thoughts on that?

 

 

I don't see why.  Linux didn't fall apart with the introduction of... tar, rpm, yum, apt, dnf, etc...

 

Just the fragmentation.  Merely not falling apart is not what I would like to see happen.  Broad adoption is better.   There is only so much time to make the switch.   Then you have to real work done again.

What a headache. 

 

I don't find it so.  What is the headache for you?  

 

is it confusion about the scope of each? Maybe we need to better communicate this?  

 

3 ways to load code.

 

 

 Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git? 

 

I believe there has been some work.  If no better answers come, search http://forum.world.st/ 

 

 

I don’t see how this will ever be done or finished manually, humans being what they are. 

 

What you a promoting is forcing a monoculture.

 

No, just Iceberg.  Do we intend to have Iceberg replace Monticello and Metacello?

 

  Humans being what they are, don't respond well to that.

  

 

Inertia, laziness, busy and tight schedules.  If we don’t have good reasons and tools to help us use the best of the tools, which I thought was Iceberg, will it ever happen?   I recall similar discussions about source management in Squeak during 2002-2004 time-frame.  It’s an old problem.

 

The fragmented versioning-technologies will persist then indefinitely.

 

Iceberg/git in only been in broad use for one year since release of Pharo 7.    

How fast do you expect the world to change?

 

What’s the plan to get everyone on Iceberg?  Is there one?

 

The diffusion of innovation applies... https://en.wikipedia.org/wiki/Diffusion_of_innovations

 

Some people work in multiple Smalltalk versions that continue to use Monticello (http://www.squeaksource.com)

and want to maintain a cross-platform package.  So even with the most perfect conversion script, Monticello will remain an option.

 

Are we using Monticello or STON to move between Smalltalks?  I thought STON was the most basic way.

 

 

The alternative scenario of having only one versioning system 

would have been to stick with Monticello and avoid using git.  

 

I don't consider that viable.  

 

Right, that’s not good. 

 

I believe Pharo has a great future with a preferred option going forward with Git

and an option to access legacy code with Monticello.

 

Is Metacello going away?

 

 

 

Shaping

 

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Thursday, May 30, 2019 08:45
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] FW: Versioning with Iceberg

 

On Thu, 30 May 2019 at 18:56, Shaping <[hidden email]> wrote:

 

I prefer to use one tool for versioning.  Is that possible now in any version of Pharo?  Can I use only Iceberg for all fetches and all commits?   Or must I sometimes use evaluables like:

 

Metacello new

 baseline: 'Exercism';

 repository: 'github://exercism/pharo-smalltalk/releases/latest';

onConflict: [ :ex | ex allow ];

 load.

 

Metacello operates at a higher level than Iceberg.  

Iceberg (like Monticello) versions individual packages.  

Metacello defines the version dependencies between packages, including different git repos and Monticello repos.  

The Metacello definition is versioned like any other code, using either Iceberg or Monticello.


I'm not completely sure, but I think Metacello uses Iceberg to load from github repos,
so what that last code snippet does is...
Metacello loads the given baseline from github using Iceberg and parses it,

then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in,

then loads all the specified code versions using Iceberg or Monticello as appropriate.

 

Also once you've loaded an Iceberg repo containing a Metacello baseline,
you can invoke that baseline from within Iceberg. 

image.png

 

Essentially Iceberg replaces Monticello for git repos,

but there is a wealth of historical packages in Monticello format, so its not disappearing either.

 

HTH,

cheers -ben

 

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

ducasse
Hi Shape 

May I suggest that you ask clear questions if you want to engage nice people to help you.

Now we as a community will not use Monticello/smalltalkhub anymore 
We are all moving to git and iceberg is really nicely working. Iceberg will get a bit more love in the future
in Pharo 80. Now we spent around 1.5 years to build it and the 450 pharo packages are managed with Iceberg
and many other projects so it works. We will probably improve iceberg again. 

We will try to make sure that we can still load MC package but since MC package are merely
zipped files you will be able to load them by loading the st file. 

Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0.

If a baseline says “load latest version” then why iceberg would load only Pharo 70 version?

So now you can get frustrated and confused. 
But did you read the booklet on how to manage code in Pharo70? books.pharo.org
Did you check the wiki and the documentation? 

Stef
Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

Shaping1

May I suggest that you ask clear questions if you want to engage nice people to help you.

 

That sounds reasonable.  Which questions weren’t clear?

 

Now we as a community will not use Monticello/smalltalkhub anymore 

 

Then officially Monticello is deprecated?

 

We are all moving to git and iceberg is really nicely working. Iceberg will get a bit more love in the future in Pharo 80.

 

I’m looking forward to it. 

 

Now we spent around 1.5 years to build it and the 450 pharo packages are managed with Iceberg

and many other projects so it works. We will probably improve iceberg again. 

 

 

We will try to make sure that we can still load MC package but since MC package are merely

zipped files you will be able to load them by loading the st file. 

 

Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it?  Is that the slow drift?

 

Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0.

 

Sure, but I’m crashing the VM, not hurting any project’s code in the image.

 

If a baseline says “load latest version” then why iceberg would load only Pharo 70 version?

 

I don’t recall the “load latest version” qualifier.

 

So now you can get frustrated and confused. 

But did you read the booklet on how to manage code in Pharo70? books.pharo.org

 

Which book are you referring to here?

 

 

Did you check the wiki and the documentation? 

 

Yes, some.  I’m thinking it’s Smalltalk and shouldn’t be that hard in any case.   But there is a lot of Git here, and that is complicating things somewhat.

 

 

Shaping

Reply | Threaded
Open this post in threaded view
|

Re: FW: Versioning with Iceberg

ducasse


On 31 May 2019, at 08:18, Shaping <[hidden email]> wrote:

May I suggest that you ask clear questions if you want to engage nice people to help you.
 
That sounds reasonable.  Which questions weren’t clear?

The first one where you were reported something I still cannot understand. 
 
Now we as a community will not use Monticello/smalltalkhub anymore 
 
Then officially Monticello is deprecated?

Yes
 
We are all moving to git and iceberg is really nicely working. Iceberg will get a bit more love in the future in Pharo 80. 
 
I’m looking forward to it.  
 
Now we spent around 1.5 years to build it and the 450 pharo packages are managed with Iceberg
and many other projects so it works. We will probably improve iceberg again. 
 
 
We will try to make sure that we can still load MC package but since MC package are merely
zipped files you will be able to load them by loading the st file.  
 
Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it?  Is that the slow drift?
No. 
Use iceberg and tonel format. 


Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0.
 
Sure, but I’m crashing the VM, not hurting any project’s code in the image.

This is another problem and we really to understand and see how we can fix it. 
 
If a baseline says “load latest version” then why iceberg would load only Pharo 70 version?
 
I don’t recall the “load latest version” qualifier.
There is none this is the default in git. 

So now you can get frustrated and confused. 
But did you read the booklet on how to manage code in Pharo70? books.pharo.org
 
Which book are you referring to here?
I will let you guess. :)

 
 
Did you check the wiki and the documentation? 
 
Yes, some.  I’m thinking it’s Smalltalk and shouldn’t be that hard in any case.   But there is a lot of Git here, and that is complicating things somewhat. 

sure it is but it also give us
visibility
scalability 
branch
less foreign from other dev

and monticello was a good soldier but it should rest now. 
 
 
Shaping

123