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). Ciao, Dscho -- 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
