Re: Google Summer of Code 2009: GIT

On Fri, 20 Mar 2009, Johannes Schindelin wrote:

Hi,

On Fri, 20 Mar 2009, saurabh gupta wrote:

quoted

On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
[off-list ref] wrote:

quoted

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.

Well, for ODF type document, we can write a merge driver which will
change the xml file in an appropriate way that OO can understand it and
the user can see the merge result/conflict in a comfortable way. As
described by Junio, in this case, a dedicated merge helper is not needed
as OO can parse the markers made by merge-driver and provide the user to
resolve the conflict and register the changes to index.

There is also the idea that OOffice has building blocks in place to help
resolving merge conflicts.  For a successful application, you will have to
show that you researched that option, and describe how well/badly it fits
with the goal of the project.

true, although for the 'simple case' of an ODF text file you can use 
text strings exactly the same way you do with a text file. the difference 
is that when inserting the two versions of things into the 'conflict' 
version of the ODF file you need to make sure that you include the 
complete open/close set of tags in each version.

for example if file 1 has

<tag1 param='1'>
text
</tag1>

and file 2 has

<tag1 param='1'>
text2
</tag1>

you can do


<tag1 param='1'>

quoted

quoted

quoted

quoted

quoted

quoted

quoted

text
========
text2
<<<<<<<<
</tag1>


but if file2 has


<tag1 param='2'>
text
</tag1>

your conflict would need to be

quoted

quoted

quoted

quoted

quoted

quoted

quoted

<tag1 param='1'>
text
</tag1>
========
<tag1 param='1'>
text
</tag1>
<<<<<<<<

(although since < and > are special characters, they would really be &gt 
and &lt in the file)

if there are nicer ways to do this, supporting them would be good, but as 
long as the marker strings are configurable you can probably do so

you could change
the first string from >>>>>>> to <conflict option='1'>
the second string from ======== to </conflict><conflict option='2'>
the third string from <<<<<<< to </conflict>

and now instead of having to search for those special text strings, your 
ODF editor would 'magicly' identify them and remind you that you hadn't 
resolved all of them.

quoted

quoted

- knowing what data types we want to support _at the least_, and what
  data  types we keep for the free skate,

As of now, how about going for XML files. For this summer, we can go for
XML files and latex files can be handled later.

If your goal is just XML files (without any more specific goal, like ODF
or SVG), I am afraid that I think that project is not worth 4500 dollar
from Google's pocket.  I mean, we are not talking peanuts here.

I see good support for XML being a superset of what's needed to support 
ODF or SVG, not a subset.

or another way of putting it, the gitconfig definition for ODF would be a 
shortcut for a longer XML definition with a long list of options.

to be accepted by google, they will need to feel that the work is worth 
the money, so defining what file types you are going to support is an 
important item. This can include saying 'by handling this type of tweak to 
an XML file we can then handle file type Y instead of just file type X 
with the same merge driver'

as you are considering this list, please think about the items I mentioned 
earlier in the thread that would improve the support for config files and 
maintainers files (unordered lines/paragraphs)

quoted

quoted

- a timeline (weekly milestones should be fine, I guess) what should
  be  achieved when, and

Timeline can be decided once we reach some conclusion and the work which
needs to be done become clear to us.

Last year, most successful applications detailed a proposed timeline in
their proposal...

Do not get me wrong, I want this project to succeed.

But on the other hand, I feel the obligation to be a bit demanding for the
gracious donation of Google: we _do_ want to have something stunningly
awesome at the end of the summer.

And that means that I have to get the impression from the student proposal
that something like that is at least _possible_.

sounds reasonable.

David Lang