On Thu, Mar 19, 2009 at 6:13 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Wed, 18 Mar 2009, david@xxxxxxx 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@xxxxxxx> 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). I do agree with you that unless an end user get to see the conflict result in an appropriate manner, there is no use of having an xml merger. But, once we decide as what will be the end file type which we will aim this summer, we can then start working whether its about making a GUI first, or creating a merge driver first. > Ciao, > Dscho > > -- Saurabh Gupta Senior, NSIT,New Delhi, India -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
