On Sat, May 19, 2018 at 2:59 AM, Cyril Ferlicot D. <[email protected] > wrote:
> Le 18/05/2018 à 21:42, Sean P. DeNigris a écrit : > > Tim Mackinnon wrote > >> Hi what does it mean “Iceberg does not manage yet upgrade of the local > >> clones” > > > > This is most commonly encountered when one enables shared repository > > location in Iceberg. Say you already have a local clone of Zinc in the > > shared root folder, but it's out of date. Then you try to load a project > > which has Zinc as a dependency, but requires the current stable version. > > Iceberg will just load from the outdated clone without trying to update > from > > the origin remote. > > > > > > This is exactly the problem! > > This is something I already described here: > https://github.com/pharo-vcs/iceberg/issues/723 > > Here is what I wrote in that thread: > > With a project on Monticello managed via a ConfigurationOf, when you > install it it will download the .mcz in the package cache and install > the project with the version/baseline you asked. > > If you ask for development, you'll get the latest packages described in > the "development" baseline. > > Now, with a project hosted on github and managed via a baseline, if the > Iceberg Metacello integration is enabled, when I ask to load the branch > "development", I'm not sure I'll get the latest version of the packages. > > If there is no local clone of the project it will clone the project and > checkout the latest version of the branch. But, if I already have a > local clone with the branch (not in sync with the remote branch), it > will install the version present locally. This version might be 5 > commits behind the remote branch. > > That's why, maybe Iceberg can check the remote branch before installing > the repository and if the local branch is behind the remote branch, it > can ask the user what to do. Either install the local version or pull > the install. > Well, there is the original discussion between Nico and Dale also from some time ago: https://github.com/pharo-vcs/iceberg/issues/168 I think asking the user is good, the thing is there are many different scenarios to think about: - the branch can already exist and be behing - the branch can already exist but diverged (merge is required!) - the repository can already exist but on another branch. Should we checkout the asked branch? With shared repositories *on* this seems weird And then, - what should happen in headless mode? Should we just cancel? - what should happen if the loading is being done by a Metacello expression Metacello new ... ... load ? Because any *new* option we introduce will introduce problems with backwards compatibility. So far the #onConflict: and #onUpgrade: allow one to do #useIncoming, #useLoaded only options. Currently iceberg works definitely better without shared repositories. > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
