It used to be that you would lose your commit message - that alone might have been reason enough to save it to the cache first. Given that the previous commit messages are now remembered, I agree it seems less important (as far as I can see anyway).
Julian On Wed, Jun 16, 2010 at 7:38 AM, Hernán Morales Durand <[email protected]> wrote: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
