Expected output:nil, as the method comment in MCRepository >> #versionNamed: states:
Answer the MCVersion with name, aMCVersionName, or nil if it doesn't exist in this repository.
Actual behavior:MessageNotUnderstood: DosFileDirectory>>resolveString: from TonelFileSystemUtils class>>directoryFromPath:relativeTo:. It might be worth noting that in [] in MCGitHubRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do:, s is a subinstance of FileDirectory (from the Files package, not squeak-filesystem).
Expected output:nil, for the same reason as above.
Actual behavior:DosFileDirectory(Object)>>errorNotIndexable. Like above, in [] in MCGitHubRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do:, s is a subinstance of FileDirectory so MCMczReader>>zip fails to read a ZipArchive from that directory.
Maybe a bit of background: The provision of MCRepository >> #versonNamed: not to raise an error but to nil is actually important because various senders, including MCRepositoryGroup >> #versionNamed: depend on this functionality in order to search for a version which's location is unknown. Since there is still a large number of senders to the MCRepositoryGroup default, a single violation of this rule like this one is enough to break the entire version search.
I'm not familiar at all with this domain but it would great if we could add a simple type check to avoid this error and maybe signal a FileDoesNotExistException somewhere in #loadVersionFromFileNamed: or below. Unfortunately, I did not find any valid usage examples of any MCFileTreeRepository subclass in combination with FileDirectory so I don't know where the invalidation begins. Maybe all these github repository instances should not be part of the default repository group at all?
Steps to reproduce:
Expected output:
nil, as the method comment inMCRepository >> #versionNamed:states:Actual behavior:
MessageNotUnderstood: DosFileDirectory>>resolveString:fromTonelFileSystemUtils class>>directoryFromPath:relativeTo:. It might be worth noting that in[] in MCGitHubRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do:,sis a subinstance ofFileDirectory(from theFilespackage, notsqueak-filesystem).Expected output:
nil, for the same reason as above.Actual behavior:
DosFileDirectory(Object)>>errorNotIndexable. Like above, in[] in MCGitHubRepository(MCFileBasedRepository)>>versionReaderForFileNamed:do:,sis a subinstance ofFileDirectorysoMCMczReader>>zipfails to read aZipArchivefrom that directory.Maybe a bit of background: The provision of
MCRepository >> #versonNamed:not to raise an error but tonilis actually important because various senders, includingMCRepositoryGroup >> #versionNamed:depend on this functionality in order to search for a version which's location is unknown. Since there is still a large number of senders to theMCRepositoryGroup default, a single violation of this rule like this one is enough to break the entire version search.I'm not familiar at all with this domain but it would great if we could add a simple type check to avoid this error and maybe signal a
FileDoesNotExistExceptionsomewhere in#loadVersionFromFileNamed:or below. Unfortunately, I did not find any valid usage examples of anyMCFileTreeRepositorysubclass in combination withFileDirectoryso I don't know where the invalidation begins. Maybe all these github repository instances should not be part of the default repository group at all?Looking forward to your help!