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
