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
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 <martin@hand2mouse.com> 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
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 <martin@hand2mouse.com> 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
hi,
On 4 Jun 2018, at 19:11, Martin McClure <martin@hand2mouse.com> 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 <martin@hand2mouse.com> 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
On 06/04/2018 11:33 AM, Esteban Lorenzano wrote:
hi,
On 4 Jun 2018, at 19:11, Martin McClure <martin@hand2mouse.com> 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
participants (2)
-
Esteban Lorenzano -
Martin McClure