Smalltalk › Pharo › Pharo Smalltalk Users

How exactly is "share repositories between images" supposed to work without tripping each other up?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Tim Mackinnon

How exactly is "share repositories between images" supposed to work without tripping each other up?

Hi - as many windows users have struggled with the long file path problem (some of which can be caused by orphaned files not even referenced in your baseline - but that were checked in) - many users have started using the "share repositories between images” and point it to a nice short file path (at least we have a workaround).

This got us running on Exercism - and unblocked our testers.

However - I was suprised when I asked one of our users to update his image to pull in some new code that fixed an issue for him (It’s the first time I've encountered a conflict and had to use onConflict - and I’m not sure why there is a conflict - but thats a side point).

Metacello new baseline: 'Exercism'; repository: '<a href="github://exercism/pharo-smalltalk:master/dev/src" class="">github://exercism/pharo-smalltalk:master/dev/src'; onConflict: [ :ex | ex allow ]; load.

So doing the above on OSX loads the update into my older image, and everything was fine. However on Windows - one of my testers tried the same thing and got a strange error:

“NotFound: failed to resolve path ‘C:\pharo\images\Exercism test\pharo-local….” (See photo below).

The weird bit is that we aren’t sure where the “Exercism test” bit comes from because his image isn’t "Exercism test” - however I suspect that this is one of the other images he created when we were testing 64 bit and he was loading into that.

So my question is - how is this shared repository supposed to work? It seems to me that different images are storing non-sharable information in the repository such that sharing can’t possibly work? As my baseline and setup are really simple - I’m suprised by this - there is literally 4 packages and one external dependency on OSProcess (which is an mcz I think). So why does this fail? I’ve always avoided the shared repository as when I initially tried it, I recall all kinds of weird behaviour - but as the windows folks can’t seem to avoid it - can someone explain what it does and what we need to look out for?

Tim

Tim Mackinnon

Re: How exactly is "share repositories between images" supposed to work without tripping each other up?

While, I’m still interested in how share repositories works (and debunk some of my myths about it ) - digging into this users issue (isn’t Fuel wonderful) - it would seem that this image wasn’t created with share repositories on.

It looking down a very complicated stack (Metacello is very complicated) - it seems like a “localGopher” object has an IceMetacelloRepositoryAdaptor in it that has this non-existent path?

It seems like it gets this path from reading packages - but heck if I know how it ended up with something that wasn’t on the users file system (although they did have an image like that at some point previous).

Anyway - if it jumps out at someone - I’d be interested, but otherwise will let it go for now.

Tim

On 6 Mar 2019, at 09:26, Tim Mackinnon <[hidden email]> wrote:

Hi - as many windows users have struggled with the long file path problem (some of which can be caused by orphaned files not even referenced in your baseline - but that were checked in) - many users have started using the "share repositories between images” and point it to a nice short file path (at least we have a workaround).

This got us running on Exercism - and unblocked our testers.

However - I was suprised when I asked one of our users to update his image to pull in some new code that fixed an issue for him (It’s the first time I've encountered a conflict and had to use onConflict - and I’m not sure why there is a conflict - but thats a side point).

Metacello new baseline: 'Exercism'; repository: '<a href="github://exercism/pharo-smalltalk:master/dev/src" class="">github://exercism/pharo-smalltalk:master/dev/src'; onConflict: [ :ex | ex allow ]; load.

So doing the above on OSX loads the update into my older image, and everything was fine. However on Windows - one of my testers tried the same thing and got a strange error:
“NotFound: failed to resolve path ‘C:\pharo\images\Exercism test\pharo-local….” (See photo below).

The weird bit is that we aren’t sure where the “Exercism test” bit comes from because his image isn’t "Exercism test” - however I suspect that this is one of the other images he created when we were testing 64 bit and he was loading into that.

So my question is - how is this shared repository supposed to work? It seems to me that different images are storing non-sharable information in the repository such that sharing can’t possibly work? As my baseline and setup are really simple - I’m suprised by this - there is literally 4 packages and one external dependency on OSProcess (which is an mcz I think). So why does this fail? I’ve always avoided the shared repository as when I initially tried it, I recall all kinds of weird behaviour - but as the windows folks can’t seem to avoid it - can someone explain what it does and what we need to look out for?

Tim
<PastedGraphic-2.png>

Sean P. DeNigris

Re: How exactly is "share repositories between images" supposed to work without tripping each other up?

Administrator

In reply to this post by Tim Mackinnon

Tim Mackinnon wrote
> how is this shared repository supposed to work?

While I initially liked the space efficiency of the shared approach, I
eventually gave up because it created too many (often obscure) problems. It
just doesn't seem to be a good match for git, although you can get away with
it in the simplest cases (read-only, no branch switching). It sounds like
you may not have the luxury of avoiding it so hopefully someone can provide
more constructive help.

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

Cheers,
Sean

philippeback

Re: How exactly is "share repositories between images" supposed to work without tripping each other up?

And then the Pharo launcher folder suddenly appears as a 20GB folder...

Same league as a Maven .m2, albeit with a messier structure, full of copies all over the place.

Is Cargo going to help us there?

Phil

On Wed, Mar 6, 2019 at 5:18 PM Sean P. DeNigris <[hidden email]> wrote:

Tim Mackinnon wrote
> how is this shared repository supposed to work?

While I initially liked the space efficiency of the shared approach, I
eventually gave up because it created too many (often obscure) problems. It
just doesn't seem to be a good match for git, although you can get away with
it in the simplest cases (read-only, no branch switching). It sounds like
you may not have the luxury of avoiding it so hopefully someone can provide
more constructive help.

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

Esteban A. Maringolo

Re: How exactly is "share repositories between images" supposed to work without tripping each other up?

In reply to this post by Sean P. DeNigris

I couldn't find a "simple enough" solution to deal with that, so I
moved to emulated Linux [1].

I don't know if the long file path is a limitation of Windows itself or libgit2.

Because if it's the former, then I'll try this setting in Windows 10
and let you know if it works:
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

Regards!

Esteban A. Maringolo

El mié., 6 mar. 2019 a las 13:19, Sean P. DeNigris
(<[hidden email]>) escribió:

>
> Tim Mackinnon wrote
> > how is this shared repository supposed to work?
>
> While I initially liked the space efficiency of the shared approach, I
> eventually gave up because it created too many (often obscure) problems. It
> just doesn't seem to be a good match for git, although you can get away with
> it in the simplest cases (read-only, no branch switching). It sounds like
> you may not have the luxury of avoiding it so hopefully someone can provide
> more constructive help.
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Dale Henrichs-3

Re: How exactly is "share repositories between images" supposed to work without tripping each other up?

In reply to this post by Sean P. DeNigris

On 3/6/19 8:18 AM, Sean P. DeNigris wrote:
> Tim Mackinnon wrote
>> how is this shared repository supposed to work?
> While I initially liked the space efficiency of the shared approach, I
> eventually gave up because it created too many (often obscure) problems. It
> just doesn't seem to be a good match for git, although you can get away with
> it in the simplest cases (read-only, no branch switching).

The use case that I have used for years (tODE and GemStone) is that I am
sharing 60+ git repositories amongst 60+ images and I want all of the
images to be sharing the same versions of all of the git projects. When
I want to do private work I create a clone that is local to the image
that I'm working in and do my work on a topic branch ... when I'm done
with the private work, I merge the topic branch back into my commonly
shared branch and then update the shared git repository so that when I
do activate one of the images.

I can quickly tell (via tools) that i have not loaded the latest shared
code into my image ... if I care (like preparing to do development), I
update to the latest shared code, so that my changes can be shared... if
I don't care, then I remember not to make any code changes that I want
to keep:)

The images that I am using are a mix different versions of GemStone, so
I _do_ make it a practice to ensure that projects I work with are all
loadable in the different versions of GemStone that I care about via
baseline changes (I use packages for version-specific code and avoid
putting version-specific code on different branches or tags) ...

So, when you say it's not "a good match for git", I don't think that it
is "git" that is the problem, but the use cases themselves are the
culprit... different tool features are very likely needed to support
different use cases ...

Dale

Ben Coman

Re: How exactly is "share repositories between images" supposed to work without tripping each other up?

In reply to this post by Esteban A. Maringolo

On Thu, 7 Mar 2019 at 02:16, Esteban Maringolo <[hidden email]> wrote:

I couldn't find a "simple enough" solution to deal with that, so I
moved to emulated Linux [1].

I don't know if the long file path is a limitation of Windows itself or libgit2.

Its a combination, but for our purposes the limitation lies with libgit2.

Issue open since April 2015... "Support `core.longpaths` on Windows "

https://github.com/libgit2/libgit2/issues/3053#issuecomment-324363336

cheers -ben