Re: Google Summer of Code 2009: GIT

[david@lang.hm]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4504 bytes --]

On Fri, 20 Mar 2009, Johannes Schindelin wrote:

> Hi,
>
> On Fri, 20 Mar 2009, saurabh gupta wrote:
>
>> On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>>> 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'>
>>>>>>>>
text
========
text2
<<<<<<<<
</tag1>


but if file2 has


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

your conflict would need to be

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

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

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