Re: Google Summer of Code 2009: GIT

On Thu, 19 Mar 2009, Johannes Schindelin wrote:

Hi,

On Fri, 13 Mar 2009, saurabh gupta wrote:

quoted

On Fri, Mar 13, 2009 at 1:29 AM,  [off-list ref] wrote:

quoted

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