Smalltalk › Pharo › Pharo Smalltalk Developers

Iceberg "Duplicated project!"

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Martin McClure-2

Iceberg "Duplicated project!"

On a Pharo7, Linux, from yesterday:
Build information:
Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9
(32 Bit)

During an Iceberg load of a Metacello baseline, I get a dialog

Duplicated project!
There is already a project "OSSubprocess" in this installation.

It's true that I do have a Git clone of OSSubprocess in my
pharo-local/iceberg directory, since this is the second image I've
loaded into, but before it's always just used the already-cloned repo
rather than trying to create a new one.

Any ideas on what the correct behavior currently is (for the system, and
for me) at this point?

Thanks,
-Martin

EstebanLM

Re: Iceberg "Duplicated project!"

hello Martin,

This is becacuse metacello finds another version already registered. Usually you can avoid that adding:

onConflict: [ :e | e useLoaded ]

and/or

onUpgrade: [ :e | e useLoaded ]

both messages act in different contexts:

onConflict: between what is in disk and what is in image.
onUpgrade: between what is in your local repo and what is asked to be cloned.

and take note that many baselines may have cyclic references (that metacello solves, at the end), this is not because you *actually* have already the project loaded/cloned.

cheers,
Esteban

> On 2 Jun 2018, at 04:42, Martin McClure <[hidden email]> wrote:
>
> On a Pharo7, Linux, from yesterday:
> Build information:
> Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9
> (32 Bit)
>
> During an Iceberg load of a Metacello baseline, I get a dialog
>
> Duplicated project!
> There is already a project "OSSubprocess" in this installation.
>
> It's true that I do have a Git clone of OSSubprocess in my
> pharo-local/iceberg directory, since this is the second image I've
> loaded into, but before it's always just used the already-cloned repo
> rather than trying to create a new one.
>
> Any ideas on what the correct behavior currently is (for the system, and
> for me) at this point?
>
> Thanks,
> -Martin
>

Martin McClure-2

Re: Iceberg "Duplicated project!"

On 06/04/2018 05:34 AM, Esteban Lorenzano wrote:
> hello Martin,
>
> This is becacuse metacello finds another version already registered.
How is it already registered? This is a fresh image. The only thing that
has happened is that it is already cloned, since I had loaded it in a
different image. Deleting the cloned repository makes it work, but fails
again on the next clean image until I delete the repository again.
This does not seem correct. It was working correctly a week earlier
(which is, I think, two Iceberg versions ago?)

Regards,
-Martin

> On 2 Jun 2018, at 04:42, Martin McClure <[hidden email]> wrote:
>> On a Pharo7, Linux, from yesterday:
>> Build information:
>> Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9
>> (32 Bit)
>>
>> During an Iceberg load of a Metacello baseline, I get a dialog
>>
>> Duplicated project!
>> There is already a project "OSSubprocess" in this installation.
>>
>> It's true that I do have a Git clone of OSSubprocess in my
>> pharo-local/iceberg directory, since this is the second image I've
>> loaded into, but before it's always just used the already-cloned repo
>> rather than trying to create a new one.
>>
>> Any ideas on what the correct behavior currently is (for the system, and
>> for me) at this point?
>>
>> Thanks,
>> -Martin
>>
>

EstebanLM

Re: Iceberg "Duplicated project!"

hi,

> On 4 Jun 2018, at 19:11, Martin McClure <[hidden email]> wrote:
>
> On 06/04/2018 05:34 AM, Esteban Lorenzano wrote:
>> hello Martin,
>>
>> This is becacuse metacello finds another version already registered.
> How is it already registered? This is a fresh image. The only thing that
> has happened is that it is already cloned, since I had loaded it in a
> different image. Deleting the cloned repository makes it work, but fails
> again on the next clean image until I delete the repository again.
> This does not seem correct. It was working correctly a week earlier
> (which is, I think, two Iceberg versions ago?)

it was not working properly.
what happened before is that iceberg was silently taking the version already present.
this may be the preferred behaviour but in other contexts is plain wrong, hence the need to force you to choose.

this is why we introduced the #onUpgrade: protocol.

btw, even if is not an “upgrade”, iceberg will fail to detect a reference to (for example) tag v1.0.0 is the same as a commit SHA (we are working on this, but it will not be anytime soon).

So, I guess you need to go for the #onUpgrade: mechanism.

cheers,
Esteban

>
> Regards,
> -Martin
>
>> On 2 Jun 2018, at 04:42, Martin McClure <[hidden email]> wrote:
>>> On a Pharo7, Linux, from yesterday:
>>> Build information:
>>> Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9
>>> (32 Bit)
>>>
>>> During an Iceberg load of a Metacello baseline, I get a dialog
>>>
>>> Duplicated project!
>>> There is already a project "OSSubprocess" in this installation.
>>>
>>> It's true that I do have a Git clone of OSSubprocess in my
>>> pharo-local/iceberg directory, since this is the second image I've
>>> loaded into, but before it's always just used the already-cloned repo
>>> rather than trying to create a new one.
>>>
>>> Any ideas on what the correct behavior currently is (for the system, and
>>> for me) at this point?
>>>
>>> Thanks,
>>> -Martin
>>>
>>
>

Martin McClure-2

Re: Iceberg "Duplicated project!"

On 06/04/2018 11:33 AM, Esteban Lorenzano wrote:

hi,

On 4 Jun 2018, at 19:11, Martin McClure [hidden email] wrote:

On 06/04/2018 05:34 AM, Esteban Lorenzano wrote:

hello Martin, 

This is becacuse metacello finds another version already registered.

How is it already registered? This is a fresh image. The only thing that
has happened is that it is already cloned, since I had loaded it in a
different image. Deleting the cloned repository makes it work, but fails
again on the next clean image until I delete the repository again.
 This does not seem correct. It was working correctly a week earlier
(which is, I think, two Iceberg versions ago?)

it was not working properly. 
what happened before is that iceberg was silently taking the version already present.
this may be the preferred behaviour but in other contexts is plain wrong, hence the need to force you to choose.

Hi Esteban,
Thanks for the explanation. I guess that makes sense. The terminology is a bit confusing -- "Loaded" is what you have on disk locally (but not in the image)? and "Incoming" is what's in the Git remote repository?


this is why we introduced the #onUpgrade: protocol.

btw, even if is not an “upgrade”, iceberg will fail to detect a reference to (for example) tag v1.0.0 is the same as a commit SHA (we are working on this, but it will not be anytime soon).

Ah, so if I'm on, say, branch "master" and my local repo is on the same SHA as the latest commit to "master" on the upstream, it will still think it's an upgrade? Nice to know that this will (someday) be smarter. I know these things take time and effort, which is appreciated.


So, I guess you need to go for the #onUpgrade: mechanism.

OK, I'll give that a try.
Thanks again,
-Martin