Hi Lauren,

I am not familiar with the MCRepositories.st file that you mention,
but it sounds like it may be part of the git integration tools. Can
someone else have a look at this please?

There is definitely an issue in MCWorkingCopyBrowser and Lauren's
patch addresses that issue, but I don't know if the fix should be
trying to interact with the file system.

Thanks!

Dave


On Sun, Jan 16, 2022 at 06:41:37AM +0000, Lauren Pullen wrote:
> Hi Dave,
> 
> On 1/16/22 00:11, David T. Lewis wrote:
> > Can you say something about how to reproduce the problem for this fix?>
> > Here is what I did:
> > 
> > - Open an Monticello browser
> > - Add a new repository (just a local file based repository for this test)
> > - Open a second Monticello browser
> > - In the second Monticello browser, remove the repository that I created in the first one
> > - Go back to the first Monticello browser, and select the repository that I deleted in other one
> That does the trick.  Tried it on my side and works out of the box to
> raise the error.
> 
> > However the fix seems to produce some other side effects that I
> > do not understand.
> If there is no MCRepositories.st file in the same folder as the image,
> it brings up a prompt to select one.  I can see how this might be confusing.
> 
> I see 2 weird effects when running #loadRepositories.  Let me know if
> any are what you're seeing.  These were already there, apparently:
> 
> My MCRepositories.st has some github repositories in it; these generate
> a single, corrupt,
> 	!MCGitHubRepository(github://nil:master)!
> entry in the repositories list when filed in.  I checked the paths and
> they do exist.  I just deleted it and re-saved.
> 
> There is a duplicate of the default package cache repository; doing
> 	MCRepositoryGroup reset.
> before loading doesn't prevent it, as that repository is always present.
>  The duplicate resists being selected, but may be deleted.  Each list
> row counts as its own index, but selecting any but the first occurrence
> visually selects the first.  This may matter for HTTP repositories with
> a user, but is fine for directories.
> 
> 	I attached a modification of the #addRepository: code.  It was using
> #== instead of #=, so it would never remove the package cache entry when
> filing in.  I can't post it to the inbox tonight, but that should fix
> one of the weird things that happens when loading the MCRepositories.st
> file.

> 'From Squeak5.3 of 30 November 2021 [latest update: #19461] on 15 January 2022 at 10:18:23 pm'!MCRepositoryGroup default addRepository: (MCGitHubRepository path: '/Applications/Squeak5.3-19459-64bit.app/Contents/Resources/github-cache/Metacello/metacello/master/Metacello-metacello-89ff194/repository')!MCRepositoryGroup default addRepository: (MCGitHubRepository path: '/Applications/Squeak5.3-19459-64bit.app/Contents/Resources/github-cache/dalehenrich/filetree/squeak4.3/dalehenrich-filetree-1a775de/repository')!MCRepositoryGroup default addRepository: (MCGitHubRepository path: '/Applications/Squeak5.3-19459-64bit.app/Contents/Resources/github-cache/squeak-smalltalk/squeak-ston/squeak/squeak-smalltalk-squeak-ston-d6ed91e/repository')!
> 'From Squeak5.3 of 30 November 2021 [latest update: #19461] on 15 January 2022 at 11:24:21 pm'!!MCRepositoryGroup methodsFor: 'update' stamp: 'lrnp 1/15/2022 23:23'!addRepository: aRepository	((repositories includes: aRepository) or: [aRepository = MCCacheRepository default])		ifFalse: [repositories add: aRepository.				self class default addRepository: aRepository].	self changed: #repositories! !
>