Ok, I have a question, it is really necessary to create and save a working copy in the default cache when the Save button is pressed and there are no valid credentials for the selected repository? Why would you need to save a new version in a cache even though you don't have permission to save in the repository you have selected in the first instance? it seems to me the Save button is saving user intentions to save in the form of new versions in a cache. It isn't supposed MC should to cache versions which are truly saved?.
(I did a funny script to confirm, creating 2000 files for free in local package-cache :) | repo wc | repo := MCHttpRepository location: 'http://www.squeaksource.com/DependencyWalker' user: '' password: ''. wc := MCWorkingCopy forPackage: (MCPackage named: 'TestSaveMC1'). 1 to: 2000 do: [ : i | | v | v := wc newVersionWithName: 'TestSaveMC1-hfm. ' , i asString message: 'nothing'. [ repo storeVersion: v ] on: Error do: [: ex | ] ] I think #canSave could answer <false> if credentials are invalid for the selected repository, and then nothing is saved in the cache presumably avoiding the ancestor/working copy mismatch that Julian has described. Also exploring the MCRepositoryGroup I've noted the useCache instVar is never disabled. This is another way to go. Opinions? Hernán 2010/6/15 Julian Fitzell <[email protected]>: > The Copy button allows you to copy the version from your cache to > whatever repository you want. I never used the debugger to fix the > problem (agreed a debugger is not very nice) but simply went to the MC > repository list, edited the repository, and then simply used Copy to > put the version where I wanted. > > I'm not saying this is the greatest behaviour ever, but it at least > allowed you to deal with the problem easily when it occurred. If > people want to come up with a better behaviour that uses exceptions > and so on, feel free; all I'm saying is that as far as I'm concerned > the current behaviour is less helpful than the previous behaviour when > this (common) error happens. > > Julian > > On Tue, Jun 15, 2010 at 2:12 AM, Hernán Morales Durand > <[email protected]> wrote: >> Hi Julian, >> >> 2010/6/15 Julian Fitzell <[email protected]>: >>> It seems that in Pharo 1.1 MC no longer displays the Version window >>> after a failed commit attempt (due to missing authentication for >>> example). As a result, cannot easily resubmit the version after fixing >>> the credentials. >>> >> >> This is the issue, http://code.google.com/p/pharo/issues/detail?id=2260 >> >> please reopen if necessary but in the old version the "Version window" >> is a pluggable standard window with a MCVersionInspector as model and >> >> 1) I saw no button to resubmit the version in this Window. The buttons >> are : Browse, History, Changes, Load, Merge, Adopt, Copy, Diff >> 2) A Debugger window was opened and used as an information dialog even >> when there's nothing to Debug (most failure cases are user errors like >> missing credentials). The Proceed button was used as Resubmit/Retry >> after the credentials were corrected. >> >> I think a version window should be displayed for a succesful save, not >> for every failed save attempt (imagine a script or a UI test which >> fails to save hundreds of packages). Actually #storeVersion: should >> trigger specific exceptions for every kind of failure so appropiate >> handlers could be implemented for different scenarios. >> >>> In fact, as I look further, it's worse than that. Let's say I had >>> version 1 and changed two methods. After the failed commit the >>> following seems to be the situation: >>> >>> - The ancestor of my working copy is 2 instead of 1 (confirmed with History) >>> - The working copy is dirty >>> - The Changes button shows the same two modified methods that I was >>> trying to save into 2 >>> - The diff between 1 and 2 shows the two modified methods >>> - The diff between 2 and my image (as selected from the History >>> window) shows no changes >> >> This is because "2" should not be created. If a copy cannot be saved >> then there is no reason to increment the version number with the >> failed attempt. May deserve another issue entry? >> >> Please comment I would like to read opinions on this. >> >> Hernán >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
