hi, > On 4 Jun 2018, at 19:11, Martin McClure <[email protected]> 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 <[email protected]> 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 >>> >> >
