From: david@lang.hm Date: Wed, 18 Mar 2009 23:55:03 GMT Subject: Re: Google Summer of Code 2009: GIT Message-ID: In-Reply-To: On Thu, 19 Mar 2009, Johannes Schindelin wrote: > Hi, > > On Fri, 13 Mar 2009, saurabh gupta wrote: > >> On Fri, Mar 13, 2009 at 1:29 AM, 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)? > 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. David Lang > How does that sound? > > Ciao, > Dscho > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >