[Pharo-dev] FW: Versioning with Iceberg
shaping at uurda.org
Thu May 30 06:55:47 EDT 2019
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:
onConflict: [ :ex | ex allow ];
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.
On 30 May 2019, at 02:07, Shaping <shaping at uurda.org <mailto:shaping at uurda.org> > wrote:
Sorry, I meant progress bar, not histo….
From: Shaping [mailto:shaping at uurda.org]
Sent: Wednesday, May 29, 2019 20:05
To: 'Pharo Development List' <pharo-dev at lists.pharo.org <mailto:pharo-dev at lists.pharo.org> >
Subject: RE: [Pharo-dev] Versioning with Iceberg
From: Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org] On Behalf Of Ben Coman
Sent: Wednesday, May 29, 2019 10:58
To: Pharo Development List <pharo-dev at lists.pharo.org <mailto:pharo-dev at lists.pharo.org> >
Subject: Re: [Pharo-dev] Versioning with Iceberg
On Wed, 29 May 2019 at 23:08, Shaping <shaping at uurda.org <mailto:shaping at uurda.org> > 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev