Re: Google Summer of Code 2009: GIT

On Thu, 19 Mar 2009, Johannes Schindelin wrote:

On Wed, 18 Mar 2009, david@lang.hm wrote:

quoted

On Thu, 19 Mar 2009, Johannes Schindelin wrote:

quoted

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

it happens.

quoted

quoted

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).

all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats 
and a single flexible XML merge driver could potentially handle all three 
(as well as other formats). for that matter, the ODF specs cover multiple 
types of data, and I suspect that appropriate conflict markers for text 
could well end up being different than the ones for spreadsheets.

that's not a 'plaything for an XML entusiast', it's making the tool 
slightly more general than it would need to be for any one of these 
formats to let it handle all of them.


but I'm not a mentor or a student, just an interested user.

David Lang