Unable to repair repository

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to repair repository

Alistair Grant
Hi Everyone,

In the latest Pharo (88c6b8d), attempting to repair the pharo
repository, i.e. clone it, first a warning is raised:

"There is no associated repository configured."

and then a DNU: #pathString was sent to nil.

The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext:
now sends #commitId instead of #shortCommitId.
IceTipRepositoryModel>>shortCommitId has an exception handler, while
#commitId doesn't.

Can someone explain why the warning was added?  It is a bit annoying
to have to click through dialogs telling me that the repository I'm
trying to create needs to be created.

Using the generic Error exception handler has the risk of hiding other
problems.  Wouldn't it be better to create a IceRepositoryMissing
error, or similar?

Thanks,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: Unable to repair repository

Guillermo Polito
Hi Alistair,

On Tue, Nov 6, 2018 at 9:39 AM Alistair Grant <[hidden email]> wrote:
Hi Everyone,

In the latest Pharo (88c6b8d), attempting to repair the pharo
repository, i.e. clone it, first a warning is raised:

"There is no associated repository configured."

and then a DNU: #pathString was sent to nil.

The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext:
now sends #commitId instead of #shortCommitId.
IceTipRepositoryModel>>shortCommitId has an exception handler, while
#commitId doesn't.

Can someone explain why the warning was added?  It is a bit annoying
to have to click through dialogs telling me that the repository I'm
trying to create needs to be created.

I've seen that yesterday evening, and I've fixed it here https://github.com/pharo-vcs/iceberg/issues/1068.
I've put links on the original issues that caused the regression, and the workaround meanwhile we prepare a new version.

A fix will be pushed in a 1.3.2 version in the following hours ^^.
 

Using the generic Error exception handler has the risk of hiding other
problems.  Wouldn't it be better to create a IceRepositoryMissing
error, or similar?

The support for missing repositories should be indeed revisited a bit and enhanced.
Particularly, we have other issues related to this that we have not worked on yet like this one:


This issue is pretty important, but no time to work on it yet, so if someone wants to propose a solution, we take it :)...
Reply | Threaded
Open this post in threaded view
|

Re: Unable to repair repository

Alistair Grant
Hi Guille,

On Tue, 6 Nov 2018 at 10:43, Guillermo Polito <[hidden email]> wrote:

>
> Hi Alistair,
>
> On Tue, Nov 6, 2018 at 9:39 AM Alistair Grant <[hidden email]> wrote:
>>
>> Hi Everyone,
>>
>> In the latest Pharo (88c6b8d), attempting to repair the pharo
>> repository, i.e. clone it, first a warning is raised:
>>
>> "There is no associated repository configured."
>>
>> and then a DNU: #pathString was sent to nil.
>>
>> The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext:
>> now sends #commitId instead of #shortCommitId.
>> IceTipRepositoryModel>>shortCommitId has an exception handler, while
>> #commitId doesn't.
>>
>> Can someone explain why the warning was added?  It is a bit annoying
>> to have to click through dialogs telling me that the repository I'm
>> trying to create needs to be created.
>
>
> I've seen that yesterday evening, and I've fixed it here https://github.com/pharo-vcs/iceberg/issues/1068.
> I've put links on the original issues that caused the regression, and the workaround meanwhile we prepare a new version.
>
> A fix will be pushed in a 1.3.2 version in the following hours ^^.

Cool, thanks!  (I had already added the exception handler to #commitId
as a partial workaround).


>> Using the generic Error exception handler has the risk of hiding other
>> problems.  Wouldn't it be better to create a IceRepositoryMissing
>> error, or similar?
>
>
> The support for missing repositories should be indeed revisited a bit and enhanced.
> Particularly, we have other issues related to this that we have not worked on yet like this one:
>
> https://github.com/pharo-vcs/iceberg/issues/949
>
> This issue is pretty important, but no time to work on it yet, so if someone wants to propose a solution, we take it :)...

I'm trying to review Pavel's PR #1953 [1], but may take a look afterwards.

Thanks again,
Alistair

[1] https://github.com/pharo-project/pharo/pull/1953