> On 13 May 2017, at 16:17, Esteban Lorenzano <[email protected]> wrote:
> 
>> 
>> On 13 May 2017, at 15:51, Thierry Goubier <[email protected]> wrote:
>> 
>> Le 13/05/2017 à 15:43, Esteban Lorenzano a écrit :
>>> 
>>> 
>>>> On 13 May 2017, at 13:16, Yuriy Tymchuk <[email protected]>
>>>> 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
>>>>> <[email protected]> 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
>>>>>> <[email protected] <mailto:[email protected]>> 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

Reply via email to