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
