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'; 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>