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: '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
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 <tim@testit.works> 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: 'github://exercism/pharo-smalltalk:master/dev/src <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>
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
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 <sean@clipperadams.com> 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
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-ov... Regards! Esteban A. Maringolo El mié., 6 mar. 2019 a las 13:19, Sean P. DeNigris (<sean@clipperadams.com>) 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
On Thu, 7 Mar 2019 at 02:16, Esteban Maringolo <emaringolo@gmail.com> 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
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
participants (6)
-
Ben Coman -
Dale Henrichs -
Esteban Maringolo -
phil＠highoctane.be -
Sean P. DeNigris -
Tim Mackinnon