Git breaks Monticello's version numbers
Locked
Git breaks Monticello's version numbers
 
|
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. |
Re: Git breaks Monticello's version numbers
|
My gut feeling is that it will be better not to mix git and MC. On Fri, May 12, 2017 at 11:09 PM, Oleksandr Zaytsev <[hidden email]> wrote:
|
|
|
In reply to this post by Oleksandr Zaitsev
Yes, please open an issue on the GitHub issue tracker (https://github.com/pharo-vcs/iceberg).
|
Re: Git breaks Monticello's version numbers
|
|
In reply to this post by Stephane Ducasse-3
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 > <[hidden email] <mailto:[hidden email]>> 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 > > |
|
|
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.
Uko > On 13 May 2017, at 09:28, Thierry Goubier <[hidden email]> 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 >> <[hidden email] <mailto:[hidden email]>> 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 >> >> > > |
|
|
> On 13 May 2017, at 13:16, Yuriy Tymchuk <[hidden email]> 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 <[hidden email]> 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 >>> <[hidden email] <mailto:[hidden email]>> 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 >>> >>> >> >> > > |
Re: Git breaks Monticello's version numbers
|
|
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 |
|
|
In reply to this post by EstebanLM
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 <[hidden email]> wrote: > > > >> On 13 May 2017, at 13:16, Yuriy Tymchuk <[hidden email]> 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 <[hidden email]> 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 >>>> <[hidden email] <mailto:[hidden email]>> 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 >>>> >>>> >>> >>> >> >> > > |
Re: Git breaks Monticello's version numbers
|
|
In reply to this post by EstebanLM
Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit :
> > >> On 13 May 2017, at 13:16, Yuriy Tymchuk <[hidden email]> >> 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 >>> <[hidden email]> 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 >>>> <[hidden email] <mailto:[hidden email]>> 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 >>>> >>>> >>> >>> >> >> > > > |
|
|
In reply to this post by Oleksandr Zaitsev
> On 13 May 2017, at 15:37, Oleks <[hidden email]> 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-tp4946939p4946997.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
|
|
In reply to this post by Thierry Goubier
> On 13 May 2017, at 15:51, Thierry Goubier <[hidden email]> wrote: > > Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit : >> >> >>> On 13 May 2017, at 13:16, Yuriy Tymchuk <[hidden email]> >>> 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 >>>> <[hidden email]> 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 >>>>> <[hidden email] <mailto:[hidden email]>> 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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> > > |
|
|
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
|
Re: Git breaks Monticello's version numbers
|
|
In reply to this post by EstebanLM
Le 13/05/2017 à 16:17, Esteban Lorenzano a écrit :
> >> On 13 May 2017, at 15:51, Thierry Goubier <[hidden email]> wrote: >> >> Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit : >>> >>> >>>> On 13 May 2017, at 13:16, Yuriy Tymchuk <[hidden email]> >>>> 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 >>>>> <[hidden email]> 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 >>>>>> <[hidden email] <mailto:[hidden email]>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > |
|
|
Could a pragmatic fix be simply... if the first-generated MC version
number is greater than 10000, then re-generate the MC version number based off the latest version number in the MC repository. But the bigger question is for... v1(MC) --> v2(git) --> v3(git) --> v4(git) --> v5(MC) what about all the intermediate commits? Do v2, v3, v4 need to make it into MC? Its the same sort of problem if you were maintaining two separate MC repos in sync, not specifically an Iceberg problem. So as Joel describes in "Let me go Back" regarding the tipping point for Excel to overtake Lotus123, perhaps we a (separate) tool in the default Image that migrates from git back to MC, as well as from MC to git. https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/ cheers -ben On Sat, May 13, 2017 at 10:42 PM, Thierry Goubier <[hidden email]> wrote: > Le 13/05/2017 à 16:17, Esteban Lorenzano a écrit : >> >> >>> On 13 May 2017, at 15:51, Thierry Goubier <[hidden email]> >>> wrote: >>> >>> Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit : >>>> >>>> >>>> >>>>> On 13 May 2017, at 13:16, Yuriy Tymchuk <[hidden email]> >>>>> 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 >>>>>> <[hidden email]> 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 >>>>>>> <[hidden email] <mailto:[hidden email]>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > |
Re: Git breaks Monticello's version numbers
|
|
In reply to this post by EstebanLM
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 <[hidden email]> wrote:
You say:
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.
That's not true. github makes it possible to run subversion against their git repositories.
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?
_,,,^..^,,,_ best, Eliot |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |