Re: Google Summer of Code 2009: GIT

> Hi,
>
> On Wed, 18 Mar 2009, david@lang.hm wrote:
>
>> On Thu, 19 Mar 2009, Johannes Schindelin wrote:
>>
>> > On Fri, 13 Mar 2009, saurabh gupta wrote:
>> >
>> > > On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:
>> > > > On Fri, 13 Mar 2009, saurabh gupta wrote:
>> > > >
>> > > > it may be just doing an XML merge driver is a summer's worth of
>> > > > work, or it may be that it's not really enough and you should try
>> > > > to do another one or two.
>> > > >
>> > > > it also may be that there is a lot of overlap between different
>> > > > merge drivers, and once you have the XML driver the others become
>> > > > fairly trivial to do. (I'm thinking the config file examples I
>> > > > posted earlier in the thread)
>> > >
>> > > with the options given to the user, one can handle the config files
>> > > also where order doesn't matter and also the whitespaces problem can
>> > > also be handled in the similar way.
>> >
>> > In my humble opinion, we should focus on the data types we want to be
>> > able to support at the end of the summer first.
>> >
>> > For example, if we decide that OOXML is a must (as it is a proper
>> > standard, and many people will benefit from it), we will most likely
>> > end up in having to write a merge _driver_ (to handle those .zip
>> > files), _and_ a merge _helper_, although we can avoid writing our own
>> > GUI, as we can create an OOXML that has its own version of conflict
>> > markers.
>>
>> do you mean OOXML (the microsoft format) or ODF (the open office
>> format)?
>
> Oops.
>
> EOVERLOAD
>
>> > If we decide that SVG is something we want to support by the end of
>> > the summer, then we can probably avoid writing a merge _driver_, as
>> > plain text is handled reasonably well in Git.  OTOH it could turn out
>> > that there are _real_ conflicts in overlapping tag ids, and it would
>> > still be easier to write a merge driver, too.
>> >
>> > IOW the details are not as important as
>> >
>> > - knowing what data types we want to support _at the least_, and what
>> >   data types we keep for the free skate,
>> >
>> > - a clear picture of the user interface we want to be able to provide,
>> >
>> > - a timeline (weekly milestones should be fine, I guess) what should
>> >   be achieved when, and
>> >
>> > - being flexible in how to support that (IOW if a merge driver appears
>> >   unnecessary first, but necessary later, we should be able to fit
>> >   that into both the design and the timeline).
>>
>> it's up to the student, but I suspect that the best approach would be to
>> start with defining a merge driver to handle XML (with a minimum set of
>> capabilities, and additional optional ones), and go from there.
>
> Well, the thing is: if the student decides to have a go at an XML driver
> first and foremost, then I'll just flatly refuse to mentor that.  Because
> I sincerely believe that this project is best designed from top to bottom,
> not the other way round.
>
> After all, the project is based on a user's request, not just a
> playthingie for an XML enthusiast (if such a thing exists).