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
<thierry.goub...@gmail.com> wrote:
> Le 13/05/2017 à 16:17, Esteban Lorenzano a écrit :
>>
>>
>>> 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.
>
>
> 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.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>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
