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>
