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 <hernan.morales@gmail.com> 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 <jfitzell@gmail.com>:
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 <hernan.morales@gmail.com> wrote:
Hi Julian,
2010/6/15 Julian Fitzell <jfitzell@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project