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>