[Pharo-dev] FW: Versioning with Iceberg
shaping at uurda.org
Fri May 31 07:03:24 EDT 2019
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 <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?
From: Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org <mailto:pharo-dev-bounces at lists.pharo.org> ] On Behalf Of Ben Coman
Sent: Thursday, May 30, 2019 08:45
To: Pharo Development List <pharo-dev at lists.pharo.org <mailto:pharo-dev at lists.pharo.org> >
Subject: Re: [Pharo-dev] FW: Versioning with Iceberg
On Thu, 30 May 2019 at 18:56, Shaping <shaping at uurda.org <mailto:shaping at uurda.org> > 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:
onConflict: [ :ex | ex allow ];
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.
Essentially Iceberg replaces Monticello for git repos,
but there is a wealth of historical packages in Monticello format, so its not disappearing either.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 70170 bytes
Desc: not available
More information about the Pharo-dev