Hi Esteban, forgive me if what I say causes conflict. I do not wish to cause conflict; quite the opposite. But I must say something on this issue as it is very important to me.
On Sat, May 13, 2017 at 7:21 AM, Esteban Lorenzano <esteba...@gmail.com> wrote: > > On 13 May 2017, at 16:17, Esteban Lorenzano <esteba...@gmail.com> wrote: > > > On 13 May 2017, at 15:51, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit : > > > > On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymc...@me.com> > wrote: > > I’m not a bit expert, but if you don’t use “metadataless” format > everything works fine with monticello. I.e. each git commit > contains all the mc history. > > > yes, but with iceberg we did another choice: we force metadataless > and do not keep compatibility with monticello. this is like that by > design: keeping the metadata was too much noise and generated a lot > of conflicts we don’t want. > > > The metadata-less format was experimented with before Iceberg because we > knew that recreation of MC-compatible metadata out of the vcs log was > already working. > > Then FileTree (and MC) was modified to make sure that the metadata-less > format would be compatible with MC. > > Now, Iceberg has decided to be non-compatible with MC. But this has > nothing to do with the underlying format. > > > Iceberg uses filetree metadataless as file format (it uses even the same > class to do the write) so what you are saying is not true ;) > What changes is that instead adding a random cypress.1 we add the a number > which is a timestamp of the commit. > > > So, using iceberg is not using git as “just another repository format > as http, ftp, etc.”. If you want to keep both versions, then you > need to save in mc format then save again in iceberg (or viceversa). > > > Which looks clumsy at best and at worse, will make the transition to > Iceberg a pain. > > > You say: > I disagree. > the cost of keeping eternal backward compatibility is not moving forward. > > I don't see how maintaining compatibility between Monticello and git versions of packages will stop you from moving forward. It /will/ make it much more difficult for members of the other Smalltalk communities that use the same infrastructure to share code with Pharo. So this breaking of compatibility makes the lives of those of us who work on the VM and the beetled compiler more difficult. in fact, it feels like an attack. I know it is not intended as an attack but it hurts. Pharos uses the VM that I have built with others. That VM originates in Squeak and is developed in Squeak, and I will, to my dying breath, try and keep the VM as something that works for both Squeak and Pharo (not to mention Cuis and Newspeak). I believe that openness in the VM's construction and use makes it stronger and more useful to us all, and trying to fork it so that it is Pharo only is a mistake. Further, I believe that that's the case for the whole ecosystem and your desire to prevent interoperability with "older" or non-git-based versions of Monticello will in the long term hurt the Pharo community much more than it helps it. So I beg the Pharo community to try and maintain compatibility with their Squeak and Cuis cousins. See where we are today with a VM that is demonstrably faster than the best commercial competitors and what a benefit this is for commercial adoption of Pharo. We are in this situation because we have been open. Attempts to close off are in my opinion extremely unwise. > > > And Peter did a very good tool to easy migrations that respect history. > > Also, nobody is forced to use iceberg: you don’t want it, do not use it. > You still have monticello. > > > as another point: nobody ask git to be compatible with svn or mercurial. > the only thing people ask is for migration tools. > That's not true. github makes it possible to run subversion against their git repositories. > and we have it. > What compatibility there is is patchy I do see git repositories not providing any compatibility with the Monticello tools to retrieve older versions. I see a confusion of different ways of interacting with git. What is the cost of maintaining compatibility and what are the benefits? What is the cost of not being compatible and what are the benefits? Esteban > > > > > Thierry > > Esteban > > > Uko > > On 13 May 2017, at 09:28, Thierry Goubier > <thierry.goub...@gmail.com> wrote: > > Le 13/05/2017 à 08:58, Stephane Ducasse a écrit : > > My gut feeling is that it will be better not to mix git and > MC. > > > It is easy to make MC compatible with Git. > > It wasn't that hard in the past, but needed a community effort > (MC being a core part of the system). Now, with the > infrastructure underway (libgit, git fast-import) it looks very > easy to implement. > > Thierry > > > > On Fri, May 12, 2017 at 11:09 PM, Oleksandr Zaytsev > <olk.zayt...@gmail.com <mailto:olk.zayt...@gmail.com > <olk.zayt...@gmail.com>>> wrote: > > Hello > > Two days ago I was trying to send the slice with my fix to > PolyMath using Monticello. But the version number got set to > 1494471195. Today I realized that all the packages to which I > commit are numbered like that. > > Cyril Ferlicot explained to me that this happens when I mix git > and Monticello commits. He suggested that I use a separate > image for committing to GitHub, or file out/file in if there is > a lot of changes to commit. > > Can this be considered a bug? Should I report it? > > I think it would be causing problems for many people. > > Oleks > > _,,,^..^,,,_ best, Eliot
