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

> 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.
>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2010/6/15 Lukas Renggli <[hidden email]>:
>>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Hernán
>
> 2010/6/15 Stéphane Ducasse <[hidden email]>:
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>:
>>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>:
>>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi Julian,
>
> 2010/6/15 Julian Fitzell <[hidden email]>:
>> 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
> [hidden email]
> 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
> <[hidden email]> wrote:
>> Hi Julian,
>>
>> 2010/6/15 Julian Fitzell <[hidden email]>:
>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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 <[hidden email]>:
>> 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
>> <[hidden email]> wrote:
>>> Hi Julian,
>>>
>>> 2010/6/15 Julian Fitzell <[hidden email]>:
>>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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 <[hidden email]>:
>> 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
>> <[hidden email]> wrote:
>>> Hi Julian,
>>>
>>> 2010/6/15 Julian Fitzell <[hidden email]>:
>>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project