Hi! > On 9 Sep 2017, at 19:43, Eliot Miranda <[email protected]> wrote: > > Hi Esteban, > > > On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On 9 Sep 2017, at 12:28, Henrik Nergaard <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >> but this is still WIP: for example timestamp needs to go to avoid >>> >> conflicts. >>> why/how would this cause conflicts versus other changes? >> >> two people modifying same method could have a marge without conflict, but if >> both modify same line (like the timestamp line), then for sure it will be a >> conflict :) > > I think this is a serious mistake. Time stamps and author marks are > important (even more important if the unit of commit is a single file for the > whole class). I'm always irritated when Monticello commits carelessly edit a > method back instead of reverting, hence lost my the original time stamp. I > want to know who edited a method when so I can ask them for help. I don't > want to see spurious changes. So making if a conflict and preserving time > stamps remains important to me.
thing is: we need to obtain that information in a different way than just put it there as text, because of conflicts. But I do not want to lose that information either… just get it in a different way. Esteban > >> >> Esteban >> >>> >>> >>> Fra: Pharo-dev <[email protected] >>> <mailto:[email protected]>> på vegne av Esteban Lorenzano >>> <[email protected] <mailto:[email protected]>> >>> Sendt: 9. september 2017 11:39:12 >>> Til: Pharo Development List >>> Emne: Re: [Pharo-dev] About Git support for windows >>> >>> >>> > On 8 Sep 2017, at 22:02, Eliot Miranda <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Hi All, >>> > >>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[email protected] >>> >> <mailto:[email protected]>> wrote: >>> >> >>> >> Hi all >>> >> >>> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>> >> others :), esteban designed a nice class file format. So that we will >>> >> not have 2Gb of space on harddisc, problems with long method names and >>> >> sluggish commits. >>> > >>> > Wow, that's great news! It'll make it much easier to import from Pharo >>> > hit repositories. Thank you, Esteban! >>> > >>> > Can someone post the grammar or a description of the syntax asap? >>> >>> I will commit it with a spec next week. >>> and I made the parser by hand and simple enough (e.g. I didn’t use >>> RBParser) so it can be ported easily to other dialects. >>> >>> Esteban >>> >>> > >>> >> >>> >> He is waiting at Wien and is probably checking everything right now. >>> >> >>> >> It is a nice format because we will be able to use it to communicate >>> >> by emails using it. So readable, compact and I like it :) >>> > >>> > Lovely! Details please :-) >>> > >>> >> >>> >> Stef >>> >> >>> > >>
