[Pharo-project] MC breakage in 1.1
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. 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 Eek! Julian
On Tue, Jun 15, 2010 at 12:12 AM, Julian Fitzell <jfitzell@gmail.com> wrote:
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.
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
Actually, most of the additional points are ok. The Changes button is, of course, relative to the selected repository (I say of course, not because that's necessarily intuitive but because I was previously aware of it) so that's why it showed the changes still. The ancestry information is all correct and opening up the package-cache to resubmit the version did get me back in business. I still think digging into the package cache to find it is not an optimum solution to this fairly common problem, though. Julian
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
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.
I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger. Lukas -- Lukas Renggli www.lukas-renggli.ch
It would be nice to fix that in a better way. Hernan we integrated your change but now the package stays dirty and if you republish in the repository then you may break the ancestor chain so I do not know what to do. Stef On Jun 15, 2010, at 7:37 AM, Lukas Renggli wrote:
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.
I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Why the ancestor chain is broken if the save failed? Of course if the fix breaks other parts I agree to revert or reopen the issue until we find a better solution. What people think about triggering specific exceptions for different failures? When I saw this issue it seemed to me no trivial to implement it to my MC knowledge at least. If nobody take it I will have a look tonight, sorry for the unwanted effects just trying to get a better Pharo experience. Hernán 2010/6/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
It would be nice to fix that in a better way. Hernan we integrated your change but now the package stays dirty and if you republish in the repository then you may break the ancestor chain so I do not know what to do.
Stef
On Jun 15, 2010, at 7:37 AM, Lukas Renggli wrote:
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.
I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ 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
What people think about triggering specific exceptions for different failures? When I saw this issue it seemed to me no trivial to implement it to my MC knowledge at least. If nobody take it I will have a look tonight, sorry for the unwanted effects just trying to get a better Pharo experience.
I think it is cool to improve that. The error message is nice, but it should leave Monticello in exactly the same state as it was before the commit. Right now it already commits a version to the cache and leaves the browser in an inconsistent state. To fix this situation it means more work than with the debugger before. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Jun 15, 2010, at 9:42 AM, Hernán Morales Durand wrote:
Why the ancestor chain is broken if the save failed?
Of course if the fix breaks other parts I agree to revert or reopen the issue until we find a better solution.
because (may be I'm wrong) your cache will contain v+1 and when you will republish v+2 its ancestor v+1 will not be saved on the server so on the server we will get v and v+2
What people think about triggering specific exceptions for different failures? When I saw this issue it seemed to me no trivial to implement it to my MC knowledge at least. If nobody take it I will have a look tonight, sorry for the unwanted effects just trying to get a better Pharo experience.
would be nice to have better exception so that we can react adequately
Hernán
2010/6/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
It would be nice to fix that in a better way. Hernan we integrated your change but now the package stays dirty and if you republish in the repository then you may break the ancestor chain so I do not know what to do.
Stef
On Jun 15, 2010, at 7:37 AM, Lukas Renggli wrote:
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.
I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ 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
2010/6/15 Lukas Renggli <renggli@gmail.com>:
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.
I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Ok then revert the change if you like, although the Debugger is probably the most powerful tool we have I see it as a tool for editing code, not configurations (I've never heard of anyone going though Debugger to set credentials in MC) and newbies may perceive a problem with MC instead of their settings or network problems. Hernán
before reverting it could we not have another solution ;) Because indeed I never went inside the debugger to catch the credentials Stef On Jun 15, 2010, at 9:25 AM, Hernán Morales Durand wrote:
2010/6/15 Lukas Renggli <renggli@gmail.com>:
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.
I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Ok then revert the change if you like, although the Debugger is probably the most powerful tool we have I see it as a tool for editing code, not configurations (I've never heard of anyone going though Debugger to set credentials in MC) and newbies may perceive a problem with MC instead of their settings or network problems.
Hernán
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In GLASS, I have arranged to prompt for new/missing credentials when the save fails due to an HTTP error ... It's a bit of a hack, since the HTTP client doesn't throw an error, but it is better than the alternative ... only experts know how to fix the credentials using the debugger:) In my case I wanted to minimize changes to the HTTP client, but I would think that for Pharo, explicit error handling would be an improvement for the HTTP client anyway... Dale Stéphane Ducasse wrote:
before reverting it could we not have another solution ;) Because indeed I never went inside the debugger to catch the credentials Stef
On Jun 15, 2010, at 9:25 AM, Hernán Morales Durand wrote:
2010/6/15 Lukas Renggli <renggli@gmail.com>:
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. I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Ok then revert the change if you like, although the Debugger is probably the most powerful tool we have I see it as a tool for editing code, not configurations (I've never heard of anyone going though Debugger to set credentials in MC) and newbies may perceive a problem with MC instead of their settings or network problems.
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
Surely the http response could be used to generate an appropriate exception/return-value to be handled in the domain (Monticello itself). I've not tripped myself up recently on the credential thing but, from memory, it was clear that credentials were the issue. Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dhenrich@vmware.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, June 15, 2010 6:11 PM Subject: Re: [Pharo-project] MC breakage in 1.1 In GLASS, I have arranged to prompt for new/missing credentials when the save fails due to an HTTP error ... It's a bit of a hack, since the HTTP client doesn't throw an error, but it is better than the alternative ... only experts know how to fix the credentials using the debugger:) In my case I wanted to minimize changes to the HTTP client, but I would think that for Pharo, explicit error handling would be an improvement for the HTTP client anyway... Dale Stéphane Ducasse wrote:
before reverting it could we not have another solution ;) Because indeed I never went inside the debugger to catch the credentials Stef
On Jun 15, 2010, at 9:25 AM, Hernán Morales Durand wrote:
2010/6/15 Lukas Renggli <renggli@gmail.com>:
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. I noticed this problem too. The previous behavior was better, at least if you knew how to fix you credentials in the debugger.
Ok then revert the change if you like, although the Debugger is probably the most powerful tool we have I see it as a tool for editing code, not configurations (I've never heard of anyone going though Debugger to set credentials in MC) and newbies may perceive a problem with MC instead of their settings or network problems.
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
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
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
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
yes this would be a good alternative. On Jun 16, 2010, at 8:38 AM, Hernán Morales Durand 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
participants (6)
-
Dale Henrichs -
Gary Chambers -
Hernán Morales Durand -
Julian Fitzell -
Lukas Renggli -
Stéphane Ducasse