May 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Thierry Goubier

Le 13/05/2017 Ã 16:17, Esteban Lorenzano a Ã©crit : > >> On 13 May 2017, at 15:51, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 13/05/2017 Ã 15:43, Esteban Lorenzano a Ã©crit : >>> >>> >>>> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)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. I'd prefer to have the git short commit ID instead. But that is my opinion. Very little is needed in MC for that numbering to be compatible. >>> 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. > > I disagree. > the cost of keeping eternal backward compatibility is not moving forward. I said nothing about eternal backward compatibility. It's interesting however that you see 'eternal backward compatibility' there. > And Peter did a very good tool to easy migrations that respect history. What Peter did could make the infrastructure a lot better. His tool can do a lot more than easing the migration. > Also, nobody is forced to use iceberg: you donât want it, do not use it. You still have monticello. For the time being... Everyone will have to cope with the migration from mcz to Iceberg at one point. Good luck to us, I guess. Regards, Thierry > >> >> Thierry >> >>> Esteban >>> >>>> >>>> Uko >>>> >>>>> On 13 May 2017, at 09:28, Thierry Goubier >>>>> <thierry.goubier(a)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.zaytsev(a)gmail.com <mailto:olk.zaytsev@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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Esteban Lorenzano

> On 13 May 2017, at 16:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 13 May 2017, at 15:51, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 13/05/2017 Ã 15:43, Esteban Lorenzano a Ã©crit : >>> >>> >>>> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)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. > > I disagree. > the cost of keeping eternal backward compatibility is not moving forward. > > 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. and we have it. Esteban > > >> >> Thierry >> >>> Esteban >>> >>>> >>>> Uko >>>> >>>>> On 13 May 2017, at 09:28, Thierry Goubier >>>>> <thierry.goubier(a)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.zaytsev(a)gmail.com <mailto:olk.zaytsev@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

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Esteban Lorenzano

> On 13 May 2017, at 15:51, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 13/05/2017 Ã 15:43, Esteban Lorenzano a Ã©crit : >> >> >>> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)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. I disagree. the cost of keeping eternal backward compatibility is not moving forward. 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. > > Thierry > >> Esteban >> >>> >>> Uko >>> >>>> On 13 May 2017, at 09:28, Thierry Goubier >>>> <thierry.goubier(a)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.zaytsev(a)gmail.com <mailto:olk.zaytsev@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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Esteban Lorenzano

> On 13 May 2017, at 15:37, Oleks <olk.zaytsev(a)gmail.com> wrote: > > So basically, this is not a bug, but the way Iceberg and Monticello are > built? > And there is no point in reporting it because it can't be fixed? It doesnât has to be fixed because is not a bug > > Oleks > > > > -- > View this message in context: http://forum.world.st/Git-breaks-Monticello-s-version-numbers-tp4946939p494… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Thierry Goubier

Le 13/05/2017 Ã 15:43, Esteban Lorenzano a Ã©crit : > > >> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)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. > 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. Thierry > Esteban > >> >> Uko >> >>> On 13 May 2017, at 09:28, Thierry Goubier >>> <thierry.goubier(a)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.zaytsev(a)gmail.com <mailto:olk.zaytsev@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 >>>> >>>> >>> >>> >> >> > > >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Yuriy Tymchuk

Okâ¦ Iâm pretty sure Iceberg did not delete my MC metadata. Maybe I used it too long ago for my project > On 13 May 2017, at 15:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)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. > > 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). > > Esteban > >> >> Uko >> >>> On 13 May 2017, at 09:28, Thierry Goubier <thierry.goubier(a)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.zaytsev(a)gmail.com <mailto:olk.zaytsev@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 >>>> >>>> >>> >>> >> >> > >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Esteban Lorenzano

> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)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. 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). Esteban > > Uko > >> On 13 May 2017, at 09:28, Thierry Goubier <thierry.goubier(a)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.zaytsev(a)gmail.com <mailto:olk.zaytsev@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 >>> >>> >> >> > >

May 13, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Esteban Lorenzano

> On 13 May 2017, at 15:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi dale > > christophe developed something like that and this is based on cargo metadata. yes, and ultimately this will be needed to have a good catalog. > > Stef > > > On Sat, May 13, 2017 at 3:04 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: > Steph, > > As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. > > I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. > > The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... > > Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. > > Dale > > [1] http://gsdevkit.github.io/GsDevKit_home/ <http://gsdevkit.github.io/GsDevKit_home/> > > [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston <https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston> > > [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston <https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston> > > [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git <http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git> > > > > On 5/13/17 12:01 AM, Stephane Ducasse wrote: > Hi guys > > right now many people publish their software on SmalltalkHUB, SS3 and Squeaksource > and this is handy to find something. > > > I hope that we will release soon the package repository that christophe was developing but > now I'm wondering if we as a community should follow a pattern to help? > > git freaks do you have suggestions > > > Stef > > >

May 13, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Esteban Lorenzano

> On 13 May 2017, at 15:04, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Steph, > > As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. there is already an umbrella project for pharo which is âpharo-projectâ. we also promote some othe rmeta projects under the âpharoâ umbrella. pharo-project pharo-graphics pharo-vcs pharo-nosql and probably some others will emerge. the reason why we donât concentrate all on one is just organisational, and we could review that on the future. > > I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. > > The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... > > Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. > > Dale > > [1] http://gsdevkit.github.io/GsDevKit_home/ > > [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston > > [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston > > [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git > > > On 5/13/17 12:01 AM, Stephane Ducasse wrote: >> Hi guys >> >> right now many people publish their software on SmalltalkHUB, SS3 and Squeaksource >> and this is handy to find something. >> >> >> I hope that we will release soon the package repository that christophe was developing but >> now I'm wondering if we as a community should follow a pattern to help? >> >> git freaks do you have suggestions >> >> >> Stef > >

May 13, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Oleks

So basically, this is not a bug, but the way Iceberg and Monticello are built? And there is no point in reporting it because it can't be fixed? Oleks -- View this message in context: http://forum.world.st/Git-breaks-Monticello-s-version-numbers-tp4946939p494… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 13, 2017